tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Klop <>
Subject Re: sessionListener.sessionDestroyed is called on shutdown of a node in the cluster
Date Fri, 18 Apr 2008 13:44:54 GMT
On Fri Apr 18 15:29:16 CEST 2008 Christopher Schultz <> wrote:
> Ronald,
> Ronald Klop wrote:
> > But why does the client still have the same session after one node 
> > shuts down. The session doesn't live on one node. It lives as long as 
> > the cluster lives.
> That's a good point.
> > I understand the Session object in the JVM is destroyed, but one part of 
> > clustering (for me) is to replicate the Session object, so the 
> > 'browser-session' lives on.
> Fair enough.
> > There is no way for me to detect if the browser-session expires or if 
> > the Session object expires except by hacking around with ugly if 
> > statements and making the deployement more difficult and fragile.
> > 
> > I think session.destroyed should only be called if the last node of the 
> > cluster shuts down. Or if the session expires by timeout.
> Unfortunately, I was unable to find any detail in the servlet 
> specification, which means that implementors are free to do what they'd 
> like in these situations. On the other hand, it means that you might 
> have an opportunity to lobby the Tomcat folks to add a configuration 
> parameter (similar to expireSessionsOnShutdown) to achieve the behavior 
> you desire.
> The problem is that sessionDestroyed can be used to support both 
> resource release (kind of like a "finally" for sessions) as well as 
> "logout" (in your case). For the former, it is very important for that 
> event to fire, even on a single node being taken out of service. For 
> others (such as yourself), it is inconvenient. It's hard to satisfy both 
> requirements.
> The Tomcat folks seem to have erred on the side of inclusivity (always 
> send the event) because there are possibilities to work around it. If 
> the event were never sent, there's no way to handle resource release at all.
> Optional configuration sounds like a good choice.
> -chris

Thanks for the explanation. I would implement the resource release stuff in a ContextListener
or by ValueUnboundListeners, but that is another discussion.
My problem isn't that big in practice. Just the accounting of logouts is not 100% correct.
I'll think about something genius to work around it. If I can't think of anything I will try
to lobby more.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message