Beware: multiple snips inside... > From: Peter Hargreaves [mailto:[EMAIL PROTECTED]] > > *) 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"/> > 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. Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
