Dear Pid,
After one Tomcat Cluster node shutdown, what kind of variables (that might
come as null) I should rely on to know that my node has been stoped.
Best Regards,
Imad Hachem
System Engineer
> From: p...@pidster.com
> Date: Wed, 18 Nov 2009 00:19:07 +0000
> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster node shutdown,
> sessionDestroyed been called before contextDestroyed
> To: users@tomcat.apache.org
>
> On 18 Nov 2009, at 00:07, Imad Hachem <hachem_i...@hotmail.com> wrote:
> > Dear Pid,
> > find below my explanation:
> >
> > 1. Manually set an attribute (e.g. MANUAL_STOP=1) in application scope
> > 2. Manually shutdown Tomcat instance.
> > 3. Tomcat expires all sessions
> > 4. Tomcat fires HttpSessionListener.sessionDestroyed for each session
> > 5. custom code checks for, and finds, attribute (e.g. MANUAL_STOP=1)
> > if(MANUAL_STOP == null){ // Tomcat Cluster Node Shutdown
> >
> > //don't do anything
> >
> > }
> >
> > else{ // case of session.invalidate or session timeout
> >
> > 6. custom code does logout per session
> > }
> >
> > 8. Tomcat fires ServletContextListener.contextDestroyed for each app
> >
> > But in fact, the variable MANUAL_STOP saved to the application scope
> > is always coming as 1, even after tomcat cluster node shutdown which
> > expected to come as null.
>
> Yes. The value 1 is expected - you're not explaining why you think it
> should be null.
>
> p
>
>
> >
> >
> >
> > I need to know if my sessionDestroyed has been called from a
> > session.invalidate Event OR session timeout OR Tomcat Cluster node
> > shutdown.
> >
> >
> >
> > Best Regards,
> > Imad Hachem
> >
> > System Engineer
> >
> >
> >
> >
> >> Date: Tue, 17 Nov 2009 16:23:16 +0000
> >> From: p...@pidster.com
> >> To: users@tomcat.apache.org
> >> CC: ihac...@lb.path-solutions.com
> >> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster node
> >> shutdown, sessionDestroyed been called before contextDestroyed
> >>
> >> On 17/11/2009 16:11, Imad Hachem wrote:
> >>>
> >>> Dear Pid,
> >>>
> >>> I am expecting them to come as null to know that the Tomcat Node
> >>> (or context) has been shutdown.
> >>
> >> That makes no sense. These are the logical steps.
> >>
> >> 1. Manually set an attribute (e.g. MANUAL_STOP=1) in application
> >> scope
> >> 2. Manually shutdown Tomcat instance.
> >> 3. Tomcat expires all sessions
> >> 4. Tomcat fires HttpSessionListener.sessionDestroyed for each session
> >> 5. custom code checks for, and finds, attribute (e.g. MANUAL_STOP=1)
> >> 6. custom code does logout per session
> >> 8. Tomcat fires ServletContextListener.contextDestroyed for each app
> >>
> >>
> >> Perhaps you can explain, clearly, what you expect to happen and
> >> where it
> >> happens?
> >>
> >>
> >> p
> >>
> >>
> >>> Best Regards,
> >>> Imad Hachem
> >>>
> >>> System Engineer
> >>>
> >>>
> >>>
> >>>
> >>>> Date: Tue, 17 Nov 2009 16:08:37 +0000
> >>>> From: p...@pidster.com
> >>>> To: users@tomcat.apache.org
> >>>> CC: ihac...@lb.path-solutions.com
> >>>> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster node
> >>>> shutdown, sessionDestroyed been called before contextDestroyed
> >>>>
> >>>> On 17/11/2009 15:57, Imad Hachem wrote:
> >>>>>
> >>>>> Dear Pid,
> >>>>>
> >>>>> I have tried to set application context variables, but it didn't
> >>>>> worked, since I m expecting to get these variables as null
> >>>>> values after node shutdown, but in fact they are coming as not
> >>>>> null.
> >>>>
> >>>> If you set them as "not null" and they are "not null" why are you
> >>>> surprised?
> >>>>
> >>>> Why do you expect them to be null?
> >>>>
> >>>>
> >>>> p
> >>>>
> >>>>
> >>>>> Best Regards,
> >>>>> Imad Hachem
> >>>>>
> >>>>> System Engineer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Date: Tue, 17 Nov 2009 15:38:22 +0000
> >>>>>> From: p...@pidster.com
> >>>>>> To: users@tomcat.apache.org
> >>>>>> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster node
> >>>>>> shutdown, sessionDestroyed been called before contextDestroyed
> >>>>>>
> >>>>>> On 17/11/2009 14:40, Ronald Klop wrote:
> >>>>>>> Hi Imad,
> >>>>>>>
> >>>>>>> Ronald. (The Ronald of the link mentioned by Pid.)
> >>>>>>
> >>>>>> Did the code supplied therein, work for you Ronald?
> >>>>>>
> >>>>>>
> >>>>>> @Imad
> >>>>>>
> >>>>>> The Servlet Spec (and therefore Tomcat) doesn't differentiate
> >>>>>> between
> >>>>>> causes of session expiry.
> >>>>>>
> >>>>>> The code requires you to set a value in the application scope,
> >>>>>> then the
> >>>>>> HttpSessionListener sessionDestroyed method checks for that
> >>>>>> value.
> >>>>>>
> >>>>>> If the value is present, you initiated shutdown. If it is not,
> >>>>>> then
> >>>>>> it's probably a session expiry and you run your logout code.
> >>>>>>
> >>>>>> Did you actually set such an attribute?
> >>>>>>
> >>>>>>
> >>>>>> p
> >>>>>>
> >>>>>>
> >>>>>>> Op dinsdag, 17 november 2009 14:36 schreef Imad Hachem
> >>>>>>> <hachem_i...@hotmail.com>:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Dear Pid,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I am running a Logout Process at each sessionDestroy.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> After applying the Cluster configuration, I don't want to
> >>>>>>>> Logout my
> >>>>>>>> Users (or run this Logout Process) after any Tomcat Cluster
> >>>>>>>> node
> >>>>>>>> shutdown, since the Session has been replicated to the other
> >>>>>>>> Node
> >>>>>>>> Cluster.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Best Regards,
> >>>>>>>> Imad Hachem
> >>>>>>>> System Engineer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> From: p...@pidster.com
> >>>>>>>>> Date: Tue, 17 Nov 2009 13:09:47 +0000
> >>>>>>>>> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster
> >>>>>>>>> node
> >>>>>>>> shutdown, sessionDestroyed been called before contextDestroyed
> >>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>> On 17 Nov 2009, at 12:11, Imad
> >>>>>>>>>> Hachem<hachem_i...@hotmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>> Dear Pid,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I have tried that code and didn't helped, note that my
> >>>>>>>>>> context&
> >>>>>>>>>> session variables are not coming as null in order to rely
> >>>>>>>>>> on to be
> >>>>>>>>>> able to differenciate between Tomcat Node shutdown&
> >>>>>>>>>> session.invalidate().
> >>>>>>>>>> I'm sorry but I don't understand what you're saying here.
> >>>>>>>>>> Tomcat& the servlet api can't tell you the difference
> >>>>>>>>>> between an app
> >>>>>>>>> shutdown and a session expiry without you writing code.
> >>>>>>>>>> What did you try?
> >>>>>>>>>> What was or wasn't null exactly?
> >>>>>>>>>> p
> >>>>>>>>>>>> Best Regards,
> >>>>>>>>>> Imad Hachem
> >>>>>>>>>>
> >>>>>>>>>> System Engineer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Date: Tue, 17 Nov 2009 11:41:20 +0000
> >>>>>>>>>>> From: p...@pidster.com
> >>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat Cluster
> >>>>>>>>>>> node
> >>>>>>>>>>> shutdown, sessionDestroyed been called before
> >>>>>>>>>>> contextDestroyed
> >>>>>>>>>>>
> >>>>>>>>>>> On 17/11/2009 11:31, Imad Hachem wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Dear Pid,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for your reply.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But can you specify exactly which Servlets API method to
> >>>>>>>>>>>> use?
> >>>>>>>>>>>
> >>>>>>>>>>> The link I sent had some code in it, did you read it?
> >>>>>>>>>>>
> >>>>>>>>>>>> Note that Tomat-5.5.12 is deployed on Production
> >>>>>>>>>>>> environment and
> >>>>>>>>>>>> we are not facing major issues.
> >>>>>>>>>>>
> >>>>>>>>>>> But you might be facing some security ones.
> >>>>>>>>>>>
> >>>>>>>>>>>> I will appreciate if you can adivse to which Tomcat
> >>>>>>>>>>>> Stable version
> >>>>>>>>>>>> we should Migrate taking in consideration that Tomcat
> >>>>>>>>>>>> Cluster is
> >>>>>>>>>>>> used in our environment as well.
> >>>>>>>>>>>
> >>>>>>>>>>> The latest: Tomcat 5.5.28. Same app, many bugfixes. Your
> >>>>>>>>>>> version was
> >>>>>>>>>>> released September 2005, over 4 years ago (that's 28
> >>>>>>>>>>> internet
> >>>>>>>> years).
> >>>>>>>>>>>
> >>>>>>>>>>> It's not good practice to avoid upgrading for that long.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> p
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>> Imad Hachem
> >>>>>>>>>>>>
> >>>>>>>>>>>> System Engineer
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Date: Tue, 17 Nov 2009 10:15:58 +0000
> >>>>>>>>>>>>> From: p...@pidster.com
> >>>>>>>>>>>>> To: users@tomcat.apache.org
> >>>>>>>>>>>>> Subject: Re: MISC; Tomcat-5.5.12; After one Tomcat
> >>>>>>>>>>>>> Cluster node
> >>>>>>>>>>>>> shutdown, sessionDestroyed been called before
> >>>>>>>>>>>>> contextDestroyed
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 17/11/2009 04:14, Imad Hachem wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Dear all,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I am using Tomcat-5.5.12 as Clustering nodes, and after
> >>>>>>>>>>>>>> one node
> >>>>>>>>>>>>>> shutdown sessionDestroyed is called before
> >>>>>>>>>>>>>> contextDestroyed.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you still using 5.5.12? Hasn't anyone advised you to
> >>>>>>>>>>>>> upgrade
> >>>>>>>>>>>>> to a
> >>>>>>>>>>>>> newer version yet?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think it's perfectly reasonably to call
> >>>>>>>>>>>>> sessionDestroyed()
> >>>>>>>> before
> >>>>>>>>>>>>> contextDestroyed().
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> How can I know if sessionDestroyed is called from
> >>>>>>>>>>>>>> session.invalidate()
> >>>>>>>>>>>>>> from the real expiration of the session or shutdown of
> >>>>>>>>>>>>>> one
> >>>>>>>>>>>>>> cluster node?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You can't know this directly from the Servlet API methods.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Note that on sessionDestroyed event, I am using a Logout
> >>>>>>>>>>>>>> behavior to
> >>>>>>>>>>>>>> logout my users from the DATABASE.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have tried to set a KEY on the context (or
> >>>>>>>>>>>>>> application scope)
> >>>>>>>>>>>>>> to check
> >>>>>>>>>>>>>> on it during the sessionDestroyed event, but it seems the
> >>>>>>>>>>>>>> context is
> >>>>>>>>>>>>>> destroyed after the session destroy event.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This comes up not infrequently on the list, the archives
> >>>>>>>>>>>>> have more
> >>>>>>>>>>>>> information:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>> http://old.nabble.com/Re%3A-sessionListener.sessionDestroyed-is-called-on-shutdown-of-a-node-in-the-cluster-p16746969.html
> >>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Is there any event listener that I can use before the
> >>>>>>>>>>>>>> sessionDestroyed to differentiate if one cluster node
> >>>>>>>>>>>>>> has been
> >>>>>>>>>>>>>> shutdown or my session has been expired?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Or is how to configure the contextDestroy to be called
> >>>>>>>>>>>>>> before
> >>>>>>>>>>>>>> the sessions destroy?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No, contextDestroyed() means that the web application
> >>>>>>>>>>>>> itself has
> >>>>>>>>>>>>> been
> >>>>>>>>>>>>> stopped, this is mandated by the Servlet Spec.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> p
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks in advance for your help.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>> Imad Hachem
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> System Engineer
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _________________________________________________________________
>
>
> >>>>>>>>>>>>>> Windows Live: Make it easier for your friends to see
> >>>>>>>>>>>>>> what yo
> >>>>>>>>>>>>>> u锟斤拷re up to on Facebook.
> >>>>>>>>>>>>>>
> >>>>>>>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
> >>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> ---------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: users-
> >>>>>>>>>>>>> unsubscr...@tomcat.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _________________________________________________________________
>
>
> >>>>>>>>>>>> Keep your friends updated锟斤拷even when
> >>>>>>>>>>>> you锟斤拷re not
> >>>>>>>>>>>> signed in.
> >>>>>>>>>>>>
> >>>>>>>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
> >>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>> ---
> >>>>>>>> ---
> >>>>>>>> ---------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-
> >>>>>>>>>>> h...@tomcat.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _________________________________________________________________
>
>
> >>>>>>>>>> Windows Live: Make it easier for your friends to see what
> >>>>>>>>>> you锟斤拷
> >>>>>>>>>> re up to on Facebook.
> >>>>>>>>>>
> >>>>>>>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
> >>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> ---
> >>>>>>>>>> ---
> >>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>>>>>> _________________________________________________________________
>
>
> >>>>>>>> Keep your friends updated--even when you're not signed in.
> >>>>>>>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---
> >>>>>> ---
> >>>>>> ---------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>>>
> >>>>>
> >>>>> _________________________________________________________________
> >>>>> Windows Live: Make it easier for your friends to see what yo
> >>>>> u're up to on Facebook.
> >>>>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
> >>>>
> >>>>
> >>>> ---
> >>>> ------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>
> >>>
> >>> _________________________________________________________________
> >>> Windows Live Hotmail: Your friends can get your Facebook updates,
> >>> right from Hotmail(R).
> >>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >
> > _________________________________________________________________
> > Windows Live: Keep your friends up to date with what you do online.
> > http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
