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
> 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
> resin-interest mailing list
resin-interest mailing list