-------- Forwarded Message -------- From: simon <[EMAIL PROTECTED]> To: MyFaces Development <[email protected]> Subject: Re: [orchestra] conversation timeouts Date: Sat, 18 Aug 2007 13:07:29 +0200
On Sat, 2007-08-18 at 12:47 +0200, Mario Ivankovits wrote: > > I briefly > > considered having an app-scope list of weak references to > > ConversationManagers, with instances adding themselves to this list as > > they are created but that has a number of difficult problems related to > > timeout/removal of http sessions. > If we are using weak references there should be no problems with http > sessions, are there? > Once the http session has been invalidated the conversation manager > should only be reachable through the weak reference (all maps have been > cleared) which means it can be gc'd. > This could work. One issue is that garbage collection only happens at some random time after the session is no longer used. So the timeout thread could end up calling into the ConversationManager even after the session has been explicitly removed. Possibly the ConversationManager could implement HttpSessionBindingListener and remove itself from the weak list. Is this called when a session is deleted? Another is that there could be potential locking issues re someone accessing a session at the same time that the timeout thread stars processing the ConversationManager in that same session. And I'm not sure what the implications are with respect to distributed sessions. This list of weak refs is at app scope, so it won't be replicated. In a proper distributed session scenario someone could be accessing a session on one machine, and the timeout thread runs on another. What happens to the session in that case? Hmm..what happens when two concurrent requests access the same session on two different machines anyway? I need to read up on distributed sessions.. > > At least this might help in dropping down to just 1 thread. So why not > try it? > > > (a) Do people think the current thread-based solution is really a > > problem? > > > Not for a 1.0 release, however, changing to the above should be easy. Agreed, there is no public API that we need to keep around so changing the internal implementation is possible after release. However this does need some kind of configuration, eg servlet init parameters, so that people can change the timeout or disable the thread creation completely. This is also needed for unit tests, as running unit tests for a timeout that runs once every 30 minutes would not be fun :-). I've started work on this.. The only other issue is that I think these thread and scalability concerns need to be documented somewhere. > > > if (a && !b) then I would suggest removing this timeout feature from the > > first release to allow time to come up with an alternative. > > > In any case, I don't think removing this feature is an alternative. IMHO > it is too important. > If we need alternatives we should try to find them now. In the worst > case, we have to delay the release. ok. Cheers, Simon
