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?


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 
> (
> 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 mailing list

Reply via email to