Re: [Resin-interest] Session death in a cluster

[Eric Kreiser]

As for #1, I have code in my SessionListener that first looks at the 
current thread and doesn't fire most of the work if it is the 
resin-destroy thread.  This is a bit of a hack - anyone else find a 
cleaner way of handling this?

thanks
Eric



On 11/19/2012 03:32 PM, Matthew Serrano wrote:
> I have a web application that creates a session for every user who logs in 
> and also tracks logins/logouts in a database. When the user logs out or when 
> the session is destroyed (using a SessionListener), I attempt to update the 
> database with the session destruction time. I experience two problems in a 
> clustered environment:
>
> 1. Shutting down one resin node in the cluster seems to kill the session on 
> that server even though the session is transferred to the other resin server 
> and remains available. So, in effect, we think users are logged out when they 
> are still active on the second server.
> 2. My database shows that some sessions seem to stay alive for days even 
> though there is clearly no activity on the session.
>
> For the first issue, is there a way to write my session listener so that it 
> knows the difference between a real session death and a transfer to another 
> clustered instance due to a shutdown?
>
> For the second issue, I found an interesting attribute on the 
> "session-config" tag 
> (http://www.caucho.com/resin-4.0/admin/clustering-ref.xtp#sessionconfig):
> invalidate-after-listener: If true, invalidate the sessions after the session 
> listeners have been called
>
> The documentation doesn't specify a default. Is it possible Resin is 
> invalidating the session before my listener has a chance to inspect it, thus 
> the listener can't update the database because the it doesn't know the user 
> information? What is odd is that most of time the database is updated 
> appropriately.
>
> Anybody else track user login behavior in a clustered environment? Going to 
> be writing a message queue analytics system that could also track this but 
> for now direct db is too simple to drop, especially when it works most of the 
> time.
>
> thanks
> matt
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Session death in a cluster

[Matthew Serrano]

I have a web application that creates a session for every user who logs in and 
also tracks logins/logouts in a database. When the user logs out or when the 
session is destroyed (using a SessionListener), I attempt to update the 
database with the session destruction time. I experience two problems in a 
clustered environment:

1. Shutting down one resin node in the cluster seems to kill the session on 
that server even though the session is transferred to the other resin server 
and remains available. So, in effect, we think users are logged out when they 
are still active on the second server.
2. My database shows that some sessions seem to stay alive for days even though 
there is clearly no activity on the session.

For the first issue, is there a way to write my session listener so that it 
knows the difference between a real session death and a transfer to another 
clustered instance due to a shutdown?

For the second issue, I found an interesting attribute on the "session-config" 
tag (http://www.caucho.com/resin-4.0/admin/clustering-ref.xtp#sessionconfig):
invalidate-after-listener: If true, invalidate the sessions after the session 
listeners have been called

The documentation doesn't specify a default. Is it possible Resin is 
invalidating the session before my listener has a chance to inspect it, thus 
the listener can't update the database because the it doesn't know the user 
information? What is odd is that most of time the database is updated 
appropriately.

Anybody else track user login behavior in a clustered environment? Going to be 
writing a message queue analytics system that could also track this but for now 
direct db is too simple to drop, especially when it works most of the time.

thanks
matt
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest