[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjms-developer
Subject:    [openjms-developer] RE: Memory Leaks
From:       "Tim Anderson" <tma () netspace ! net ! au>
Date:       2005-04-20 15:05:32
Message-ID: 000001c545ba$673ef520$9b7cfddc () xerces
[Download RAW message or body]

I'd like to get an alpha of 0.7.7 out in the next few weeks.
After that, I'll go back and look at releasing 0.7.6.2.
I wouldn't expect 0.7.6.2 before the end of May.

-Tim

> -----Original Message-----
> From: Moore, Randy 
> [mailto:openjms-developer-admin@lists.sourceforge.net] On 
> Behalf Of Moore, Randy
> Sent: Wednesday, 20 April 2005 5:02 PM
> To: openjms-developer@lists.sourceforge.net
> Subject: 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openjms-developer
> 
> 
> End of openjms-developer Digest
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
openjms-developer mailing list
openjms-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openjms-developer
[prev in list] [next in list] [prev in thread] [next in thread]