With the janitor, do you mean the StoreJanitor? Therefor, a ContinuationManagerImpl should somehow be registered in the StoreJanitor, or do I miss your point.
Well, janitor as in "cleaning up" ;-) ...I was not referring to a certain class. But you are right it would probably be the ContinuationManagerImpl. Janitor is often used for such clean up mechanisms.
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?
Either when "low on memory" ...and/or "hasn't been used for a certain amount of time". The big difference would be to have a maximum number continuations which might "accelerate" the expiration when running out of slots in the LRU list.
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.
Well, of course it would be up to you to profile ...but then you should be able to control things better. 100MB for 200 continuations? Sorry, there must be something wrong! I am not so fluent with javascript flow but when I serialize a javaflow continuation it's often less than 5-10kb per continuation.
Anyway, a janitor freeing continuation according LRU to prevent OOM is good to have.
For sure ...so will you do it? *nudge* ;) The continuation management needs an overhaul anyway (...to support serialization with javaflow from within cocoon e.g.) cheers -- Torsten
