Re: [opendds-main] Possible memory leak in v 2.3-RT14855-1

[Leeland A. <la...@re...>]

Hello Adam,



Thanks for the response. I am still poking at this. I found that by going
with all the defaults except for setting the transport protocol to RELIABLE
everything seems to work correctly without the ever increasing memory usage
(which looks like a leak but really isn’t).



We are not setting a key in the pragma file. So I believe each sample or
message is getting a unique key. So my belief is that even if all the
subscribers have lost connections for extended time periods the publisher
will still queue up all incoming messages until it runs out of memory and
crashes. So once the subscriber comes back online there is a basic “gush”
of queued up messages to process and the memory is then de-alloc’d
correctly. I have run some tests simulating 12 or more hours without
subscribers reading the queues with this configuration and it seems to be
doing this.



The basic behavior we are targeting is one or more publishers have a queue
of samples to be delivered to any ONE subscriber. We want to never drop a
message until it is handed off to a subscriber.



My other issue right now is if I hook up two subscribers the publisher
essentially divides up the messages round robin style between them. This is
fine, but when one subscriber goes down poorly (i.e. just drops) the
publisher queues up messages for that subscriber still in a round robin
style. This is not the behavior I am after. I essentially have dozens of
messages to be passed to one and only one subscriber for processing.
However, any subscriber will do, and if a subscriber goes down I want the
messages to just be picked up by any subscriber asking for the next message
in a first in first out style.



We are kind of stuck with the 2.4 because it seems to be a huge amount of
work to change up to the 3.x opendds. I have however, managed to upgrade to
the latest final 2.4 release.



Being new to all of this I am still trying to figure out all the moving
parts. :^)



+ Leeland





*From:* Adam Mitz [mailto:mi...@oc...]
*Sent:* Wednesday, December 28, 2011 1:06 PM
*To:* Leeland Artra
*Cc:* ope...@li...
*Subject:* Re: [opendds-main] Possible memory leak in v 2.3-RT14855-1



Hi Leeland,

On 11/8/2011 11:13 AM, Leeland Artra wrote:

Hello Adam,



Your comment on the history keeping might indeed be the issue. I found
another section of code that had this additional comment:



  //We don't want to lose any messages so setting the history to keep all
and set limits to unlimited

  dr_qos.history.kind = DDS::KEEP_ALL_HISTORY_QOS;



Which seems wrong to me. What we really want is for all messages to be
assured of being passed on to the subscribers. What would you recommend I
set these parameters to?




I don't think there's one right answer to the HISTORY QoS settings.  The
snippet of code you've shown is "dr_qos", so I assume that's for the
DataReader.  KEEP_ALL_HISTORY_QOS should be OK here unless you notice a lot
of memory use.  Your application code will most likely be calling some form
of take() on the Data Reader so it doesn't need to hold on to the data
forever.

Setting HISTORY on the Data Writer can be more difficult.  KEEP_ALL can
lead to large memory use (not leak) in the Data Writer, but too small a
number can lead to samples being replaced before they're sent.  I think
this large memory use may be an implementation artifact so let us know if
you're interested in developing or funding a fix for that.


As far as the id_ I am still trying to figure out where that is set, how it
is tracked, etc.


None of the HISTORY settings will make much sense for your application
until you determine how you'd like to divide the data samples into
instances.  Is there only one instance (no key fields), or one instance per
data sample (one key field with a different value for each sample), or
something in between?

Thanks,
Adam Mitz
Senior Software Engineer
Object Computing, Inc.