> <snip/> > > IMO the only way to solve this transparently is to more accressively > expire and limit the number of continuations. It would make sense to > come up with a LRU list of continuations per session. This list has a > maximum size that can defined. So the required maximum can is > predictable. Generating more continuations means using free slots or > throwing away the oldest ones in that LRU list. The janitor would > basically only go through the list and expire to free the slots in > that list.
With the janitor, do you mean the StoreJanitor? Therefor, a ContinuationManagerImpl should somehow be registered in the StoreJanitor, or do I miss your point. Then, if low on memory, the StoreJanitor (perhaps its name is a little awkward when it also manages the continuations), should somehow figure out wether to free memory from cache or from continuations (or both), right? Expiring them aggresivily is not always possible (people might need an hour to fill in a form, this means by default all cont live for an hour. I think though you can specify a ttl for each cont, isn't? ). Also setting a limit might be quite tricky, because it sometimes is quite difficult to know in advance how large your cont in memory will be (we had in flow a closure that did a cocoon.processPipelineTo before a handleform() that took about 100Mb for 200 continuations!). You can't expect users to really know all this and know in advance with X memory they have Y continuations. Anyway, a janitor freeing continuation according LRU to prevent OOM is good to have. Regards Ard > > cheers > -- > Torsten >
