Hi All, Currently orchestra has a feature that causes conversations that have not been accessed within 30 minutes to automatically be deleted. Similarly, conversation-contexts that have not been accessed within 30 minutes also get deleted.
I don't personally see the use of this, but have been assured it is important. And Seam has this feature, so I suppose we need to offer it too :-). The current implementation is for a Thread to be spawned for every ConversationManager instance, ie for *every http session*. This thread periodically wakes up and scans its associated ConversationManager to check for context or conversations that are too old. I'm concerned firstly about creating threads in a jee environment; the jee spec says this should not be done. Secondly, I'm worried about the scalability: a system with 1000 users will have 1000 threads created. These will mostly just be sleeping, but threads are still not light-weight objects. And thirdly I'm worried about the implications for distributed sessions. The thread will be created only on the server on which the ConversationManager (cm) is first created, because the thread is created in the cm constructor. This thread then holds a hard reference to the cm instance it is to scan. I don't entirely understand what happens when sessions start to get replicated between servers but it seems that there is potential for problems here. Note that Orchestra will probably not be compatible with distributed sessions in its first release (there are a number of issues to look at) but I think it would be nice to be able to make this work at some time in the future. Unfortunately, I can't think of a good alternate solution at the moment. Checking for timeouts for the session of user X cannot rely on user X making regular requests. But AFAIK, there is no way for code to be able to retrieve a list of all http session objects in the server. 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. So: (a) Do people think the current thread-based solution is really a problem? (b) If yes, and someone has an idea for an alternate solution, please speak up! if (a && !b) then I would suggest removing this timeout feature from the first release to allow time to come up with an alternative. Regards, Simon
