[orchestra] conversation timeouts

[simon <sk...@apache.org>]

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

Re: [orchestra] conversation timeouts

[Adam Winer <aw...@gmail.com>]

Mostly ignorant of orchestra, but:
Could you hitchhike on other requests?  On any request,
look through a conversation list, and any that haven't
been accessed within 30 minutes get deleted.
If no requests are coming in, then one really doesn't
care about excessive resource use. :)

Finding a way to make this strategy work that is
adequate in the face of session failover would be very
tricky, though.  OTOH, I don't see the problems as
worse than the Thread-based solution.  My biggest
concern with an approach of this sort is security -
accessing one session's information from a different
session seems like setting yourself up for major problems.

-- Adam


On 8/18/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 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 :-).
> >
> One reason is to keep resources low. A conversation can have accessed a
> huge amount of database records, for every record the EntityManager hold
> an entities in its session cache ... resulting in a major memory
> consumption.
>
> > 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.
> >
> The main idea of a thread is to be lightweight, no?
> But I see the point, in terms of 1000 users it might be no longer
> lightweight.
>
> > 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.
>
> 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.
>
> > 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.
>
> Ciao,
> Mario
>
>

Re: [orchestra] conversation timeouts

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> 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 :-).
>   
One reason is to keep resources low. A conversation can have accessed a
huge amount of database records, for every record the EntityManager hold
an entities in its session cache ... resulting in a major memory
consumption.

> 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.
>   
The main idea of a thread is to be lightweight, no?
But I see the point, in terms of 1000 users it might be no longer
lightweight.

> 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.

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.

> 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.

Ciao,
Mario

Re: [orchestra] conversation timeouts

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
>> 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.
>>     
>
> 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.
>   
I don't see that DBCP and e.g. HTTP Session timeout is comparable.
With DBCP the developer clearly has a chance to provide a clean code
which returns a borrowed connection - this is not the case for a HTTP
Session nor for a conversation.
The user can close a window or the browser or navigate to some other
place within the application and you just couldn't know that.
If the user came back to a page and the conversation is still active,
fine, it is likely to assume that he/she would like to continue the
work. If not, its clearly that we have a stale object which we have to
get rid of.
However, having a conversation-timeout=0 could be possible to disable
any automatic cleanup - for those who requires it.

IMHO a conversation or dialog timeout is in the same level than the
session timeout, and no one would argue that we have to deal with that.
Being able to disable it would be a fine addition, though.

Ciao,
Mario

Re: [orchestra] conversation timeouts

[Rahul Akolkar <ra...@gmail.com>]

On 8/18/07, simon <sk...@apache.org> 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
>
>