com.rti.dds.infrastructure.RETCODE_OUT_OF_RESOURCES on keep all history

5 posts / 0 new
Last post
Offline
Last seen: 4 years 2 weeks ago
Joined: 05/21/2014
Posts: 46
com.rti.dds.infrastructure.RETCODE_OUT_OF_RESOURCES on keep all history

I am using a keep all history Qos for a datawriter for a topic and after n writes of data with the writer I get the following message

com.rti.dds.infrastructure.RETCODE_OUT_OF_RESOURCES

Why is this error happening and is there anyway to solve this error?

jcwenger's picture
Offline
Last seen: 2 years 11 months ago
Joined: 01/21/2015
Posts: 11

A keep all history QoS tells the middleware you want to keep a copy of every single sample that has ever been recieved.  Every sample you store uses up some amount of memory.  When you never throw any away, you inevitably run out of memory.

Solutions:

  1. Use a sane limit on the number of samples in the history.
  2. Add a lifespan QoS policy.  Samples that are older than the duration of their lifespan will get taken out of the DataReader Cache.
  3. Use take() to explicitly release the middleware from storing some specific samples that match a criteria that indicates they're no longer relevant to retain.
  4. Spend some time thinking about why you're asking the middleware to retain a copy of every single message ever received by the system.  It's probably not a good idea.
Offline
Last seen: 4 years 2 weeks ago
Joined: 05/21/2014
Posts: 46

Thanks I was afraid that, that was happening. Is there anyway to also increase the memory size that is used without any hardware update or is that set to a hard number? Oh and not every single message just a certain topic that is sending data that we don't want ever to get lost.

Gerardo Pardo's picture
Offline
Last seen: 1 day 6 hours ago
Joined: 06/02/2010
Posts: 601

It is not hard-coded. There are default values but everything is configurable. Several QoS settings control the resources used by the DataWriter. The most significant one is the RESOURCE_LIMITS QoS Policy on the DataWriter and the corresponding RESOURCE_LIMITS on the DataReader.

Also you could separate the data into different Topics or use different DataWriters even if they publush to the sama Topic. That way you only have to configure with HISTORY KEEP_ALL the things for which every message must be kept and delivered. Others you can configure with HISTORY KEEP_LAST.

Gerardo

 

 

Offline
Last seen: 4 years 2 weeks ago
Joined: 05/21/2014
Posts: 46

Thank you for the information Gerado. Yes I have seperated into different topics so for example topic foo keeps a depth of 10 and topic bar is the one that keeps all history with using the same Qos file but different profile within. I actually did figure out a soltuion with impleenting my own queue and keeping a depth of only 1 now. Since I realized increasing the limit really just delays the problem but for my case won't solve per say.