RE: Memory Leaks

Tim,

I changed my publisher to allow a 30,000 milli-second time to live and the publisher was already throttleing the messages (around 300 at a time with 2500 milli-second sleep between bursts). I still get the out of space error, It's not necessary to Persist these messages because the info was already saved to a DB before the publish. And the subscriber client knows to re-read the DB after temporarily disabling the subscription. Unfortunately, I still have the memory leak problem.

I like option two below, but I think I'll hook this up to a memory profiler and see if I can find some other cause. 

When do you anticipate the next stable release of OpenJMS?

Randy

 
There's no new strategy for dealing with this yet in the
latest CVS, although it shouldn't be too hard to implement.

A couple of potential implementations would be to:
1. discard old NON_PERSISTENT messages when a particular
  no. is reached
2. discard old NON_PERSISTENT messages when free memory falls
  below a certain threshhold, irrespective of JMSExpiration property.
3. prevent publication of messages, once a particular no.
  is reached.
4. prevent publication of messages when free memory falls
  below a certain threshhold.

I suspect (2) would be the most useful, but I would be 
interested to know what others think.

Thoughts?

-Tim

> From: Moore, Randy 
> 
> Hi Again,
> 
> I've been experimenting with version 0.7.6.1 and am 
> publishing objects (NONPERSISTANT) to a Topic via the TCP 
> mode. At present I only have on subscriber running, but plan 
> to have multiple ones. Anyway, I publish in bursts of 300 
> objects every 2.5 seconds, and my consumer gets all of them 
> without problems. However. after I send out a total of around 
> 50,000 objects, I get an out of memory exception in the 
> JMSServer. I know I could increase the memory for the JVM, 
> but it appears to me that would only delay the inevitable. We 
> are probably dealing with a memory leak and I was curious if 
> the latest CVS build may have some fixes for these types of 
> problems. With the exception of this problem, I'm quite happy 
> with OpenJMS. It gives me the messaging I need for a near 
> real-time application, without the bloat of a fullup Web or 
> Application server.
> 
> Thanks 
> 
> Randy
> 




--__--__--

_______________________________________________
openjms-developer mailing list
openjms-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openjms-developer


End of openjms-developer Digest