Hi Vadim, [EMAIL PROTECTED] wrote:
> 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"/> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
