Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38BC8073.8EE887C9@apache.org>
Date: Wed, 01 Mar 2000 03:29:07 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Memory Store and JDK 1.2
References: <000201bf82d3$c27c4e60$0c00000a@trantor>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michel Lehon wrote:
> 
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> >> From: Michel Lehon [mailto:michel.lehon@outwares.com]
> >> It looks like JDK 1.2.2 under Win98 keeps all
> >> SoftReferences alive unless it
> >> really runs out of memory, at that time it clears all
> >> SoftReferences in one
> >> go (so the complete cache is cleared).
> >
> > Ouch, this is not that useful. I like the newer system in 1.7
> > that calls
> > the cache-cleanup if an OutOfMemory error is caught.
> >
> >> I know that the current JDK for Cocoon is 1.1 not 1.2.
> >> However I though this might be useful for some user that
> >> use JDK1.2 and
> >> still experience OutOfMemoryExceptions.
> >> The current implementation is very simple. It could be
> >> improved by mixing it
> >> with a classic cache algorithm.
> >
> > Hmmmm, the 1.7 MemoryStore is pretty complete on that side and yes, it
> > should be far better for the JVM to implement that soft references on
> > its own... but if the behavior is that bad, I prefer to use what we
> > have.
> >
> 
> To be honest I prefer the 1.7 way to handle things right now (looping until
> it gets enough memory freed by the store).
> But it has one big draw back... It only works if the OutOfMemoryException is
> thrown by Cocoon.

Oh, shit. You're right... didn't thought about that :(

> What happens if another Servlet needs more memory and fails to get it ? I
> don't really know but I guess the JVM
> tries to recall what it can... if it still fails it will just quit with the
> error message. 

I've added some logging messages to the OutOfMemory loop and even under
big load I didn't have any exception thrown... so you might consider it
the last line of defense... but your point still holds true.

> The JVM will never call the cocoon cache's flush method.
> This was one of the aims of this test implementation using SoftReferences,
> they would be cleared by the JVM
> regardless of the location of the OutOfMemoryException.

You're totally right.
 
> However I'm disapointed too that the JVM is not more clever when it clears
> these references.

Yep. James, do you know anything more about this?
 
> I'll do more testing to get a clearer picture of what is happening.
> I hope to find a way to avoid the whole cache to be cleared... gone
> hunting...

Great, I'll wait for your comments on that.

> >Thank you anyway for the suggestion, I'll keep it in mind for the next
> >releases in case the OutOfMemory error is not solved.
> 
> Well that was the aim... get a few of the remaining brain cells away...
> (when Cocoon 2 goes prod. You'll get your beer to get rid of the last ones).

No kidding. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------