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

[Adam M. <mi...@oc...>]

Hi Leeland,

On 12/28/2011 5:33 PM, Leeland Artra wrote:
>
> 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.
>

There's a lot of info here, but none of it leads me to a response.  If 
you have specific questions about the DDS spec or how OpenDDS works, we 
can try to answer them on the mailing list.  For in-depth consulting or 
development work on your application I'll have to suggest our commercial 
support services.

> 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.
>

The upgrade should not be a huge amount of work.  It mostly involves 
removing code that's no longer necessary.  See the document 
OpenDDS_3.0_Transition.txt in the "docs" directory.

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

If you don't mind one more plug here, we do offer training classes.


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