Hi, >>>>*) 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. > >That's when you tune for one particular application - then yes. If you >try to put something that works well when you have 200 huge objects, and >when you have 20000 tiny one - I think defined number won't work. What >can you suggest here? I hoped that percentage may work for these >situations. > > >> When I tried removing a percentage, I found that successive attempts >> freed up less and less storage > >This makes sence, I did not thought of it this way... > >then my system ran out of memory before the store was empty. > >...but on the other hand: it means that you have leaks in some other >place! May be you will want to find them first before blaming memory >store ;) >It may be not leaks, but uncontrolled memory consumption by some >business logic of your site. Then why not just increase free-memory >parameter to factor in these requirements?
That's correct. I noticed that calling the gc before freeing is very useful. Because I determined that this frees mainly enough memory and therefor objects don't have to freed out of the store. Be careful. There are other garbage in the JVM, not only the stores ;). I wouldn't concentrate that much on the stores. NOTE: often there are only 100 objects in the cache. But if you ever seen a Cocoon StackTrace then you know how much objects we instantiate ;). >> The trouble with convincing people is that you have to unconvince them >> if you change you mind ;-) > >:) I know, I know... >>>>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. > >Don't know. Search bug database - may be there is already couple of >requests in there. Keep talking ~Gerhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
