Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 56872 invoked by uid 500); 27 Jan 2002 23:35:26 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 56861 invoked from network); 27 Jan 2002 23:35:25 -0000 From: "Gerhard Froehlich" To: Subject: RE: Store Janitor Hangs System Date: Mon, 28 Jan 2002 00:35:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000701c1a783$9bce0890$0a00a8c0@vgritsenkopc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > > >> > 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 int size(). 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 Enumeration keys() and determine so the size elements in the store. That would be possible. 1/10 I like. Half is a little bit krass. 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