On 8/18/07, simon <[EMAIL PROTECTED]> wrote:
> 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 :-).
>
<snip/>
This came up [1] in relation to Shale dialogs [2], and some of the
things you bring up here along with trying to encourage better
developer discipline have kept us from introducing any notion of
dialog timeouts there till date.
-Rahul
[1] See bottom half of this post and subsequent replies in that thread:
http://www.nabble.com/How-to-handle-links-outside-a-SCXML-Dialog--tf3995105.html#a11358084
[2] http://shale.apache.org/shale-dialog/
> 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
>
>
