cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hargreaves <pdha...@netscape.net>
Subject Re: StoreJanitor new calculation [was: Re: Store Janitor Hangs System]
Date Tue, 05 Feb 2002 00:54:53 GMT
Hi Vadim,

vadim.gritsenko@verizon.net wrote:

> Beware: multiple snips inside...
> 
> 
>>From: Peter Hargreaves [mailto:pdhargr@netscape.net]
>>
>>*) Calling the gc once every check interval seriously undermines
>>
> system
> 
>>performance because it can take several seconds to complete, which is
>>comparable to the check interval. Why not call it only when some items
>>are released from a store? Why not trust it and use its
>>
> characteristics
> 
>>to advantage?
>>
>>*) When several instances of Cocoon are running (independent .WAR apps
>>in the same servlet container), the calls to gc become very dominant.
>>Would this affect the strategy for store-janitor settings?
>>
> 
> +1 on reducing gc() calls whenever possible.
> 
> 
> 
>>*) If the percent to reduce storage is set to 10%, it fails to remove
>>any when the number of items are below 10. The number of items to be
>>removed needs rounding upwards. Why not remove a fixed number of items
>>instead of a percentage? (My idea and now I think it was wrong!!)
>>
> 
> +1 on rounding up,
> -1 on removing percentage. Applications highly differ on number of
> objects and average size of the object. Percentage gives the advantage
> to have generic configuration. If this is not over-configuration, number
> of objects to remove may be configured with or without percent sign:
> 
>   <parameter name="reduceby" value="10%"/>
>   <parameter name="reduceby" value="100"/>


My thinking is this. Ideally you want to remove a defined number of 
bytes from the stores. If you can guess the average size of an item then 
   by removing a defined number of items you are removing an approximate 
number of bytes.

When I tried removing a percentage, I found that successive attempts 
freed up less and less storage then my system ran out of memory before 
the store was empty.

The trouble with convincing people is that you have to unconvince them 
if you change you mind ;-)


> 
> 
>>2.5) Then call the garbage collector, but only if some memory items
>>
> were
> 
>>freed.
>>
> 
> Do we need to call gc() at all? I suppose that if memory is really low
> gc() will be called at next new().
> 
> 
> 
>>The above solution is implemented and tested and it works very well
>>indeed for me. The parameters do not seem to be at all critical -
>>
> thank
> 
>>goodness! I see no reason why the default settings would need to be
>>changed if more memory were available. I have attached the
>>StoreJanitorImpl.java so others can test it. I find I can get a very
>>good picture of what is happening by using my editor's repeat find
>>command on the debug output in the core.log.000001 file. Optimizeit is
>>no longer necessary to prove that it works effectively.
>>
> 
> That's sounds promising.
> 
> 
> 
>>Ideally - low memory should be detected by some sort of interrupt or
>>exception rather than by polling.
>>
> 
> AFAIK, when you get an exception it's already late to take any action.


Ah, but what about the undo command. Or the retrospective exception 
handler. You know the one I mean - "It was left at that previous junction".

Seriously though. Are there any plans for java to include a mechanism 
that tells folks when memory is getting low. Surely lots of people have 
this problem.


Peter



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


Mime
View raw message