cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: StoreJanitor new calculation [was: Re: Store Janitor Hangs System]
Date Mon, 04 Feb 2002 18:37:02 GMT
Beware: multiple snips inside...

> From: Peter Hargreaves []
> *) Calling the gc once every check interval seriously undermines
> 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
> 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"/>

> 2.5) Then call the garbage collector, but only if some memory items
> 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 -
> goodness! I see no reason why the default settings would need to be
> changed if more memory were available. I have attached the
> 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.


To unsubscribe, e-mail:
For additional commands, email:

View raw message