cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: Store Janitor Hangs System
Date Sun, 27 Jan 2002 23:35:32 GMT
Hi,
yes, there arn't such things like boring sundays with Cocoon
(TANSTLBSWC).

>From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
>> From: Peter Hargreaves [mailto:pdh@totalise.co.uk]
>> 
>> Hi Folks,
>> 
>> Its great to see such enthusiasm - thanks for listening. Just got a
>> coupe of comments and a simple idea that might help towards the
>solution
>> - if you scroll down.
>> 
>> Gerhard Froehlich wrote:
>
><snip/>
>
>>  > Maybe I did something wrong. But the idea was that:
>>  >
>>  > while(MemoryIsLow) {
>>  >   free objects out of the store //physicall
>>  >   run gc
>>  > }
>>  >
>>  > I run the GC after each "free objects" to clean away
>>  > does not needed objects!
>>  >
>>  > The problem is now, that when he doesn't has anything
>>  > to free from the registered stores, he runs the GC
>>  > all the time. And then we have this endless loop!
>>  >
>>  > Therefore I should check if the Stores are empty. If they
>>  > are empty and there is nothing to free anymore we should
>>  > leave that loop.
>> 
>> 
>> Is this where you mean:
>> 
>>     while (this.memoryLow() && this.getStoreList().size() > 0) {
>>         this.freeMemory();
>>     }
>> 
>> I assumed that "this.getStoreList().size()" returned 0 when all the
>> stores were empty. If this is not the case (as you suggest) then it
>> looks like a permanent loop. I have seen it come out of this loop
>> however. Perhaps another thread freed up memory letting the gc become
>> successful at breaking out of the loop through "this.memoryLow()".
>> 
>> I saw it break out of the loop when I had the jvm -Xnoclassgc option
>> set. With this option classes that haven't been used for a while get
>> dropped from memory don't they? So, if stuck in a loop, it won't be
>long
>> before there are a lot of classes that haven't been used for a while!
>> When I saw it come out, it was spectacular - a sudden big drop in
>memory
>> in use!
>> 
>> 
>>  >  >> After that it waits as configured (threadinterval)
>>  >  >> before the next execution.
>>  >  >>
>>  >  >> Maybe there is a more elegent solution.
>> 
>> 
>> Hava you considered a sort of binary approach to emptying stores?
>> 
>> while (MemoryIsLow) {
>>      free half of the items in the next store
>>      run gc
>> }
>
>I guess half would be too radical :)
>May be something like 1/10th (decimal approach) would do the job better?

Everything no problem *if* the Store interface would have a method like
<code>int size()</code>. But it doesn't provide this in the moment. And we 
all no how people react, when we change a work interface. But I can change 
the implementation of <code>Enumeration keys()</code> and determine so the 
size elements in the store. That would be possible.

1/10 I like. Half is a little bit <german>krass</german>. Think about that
chain picture Stefano drawed.

  Gerhard

--------------------------------------------
Very funny, Scotty. Now beam down my clothes.
---------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message