Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <bsouther@fwdco.com>
Subject: RE: sessionS info persistence when restart Tomcat
From: Ben Souther <bsouther@fwdco.com>
Reply-To: bsouther@fwdco.com
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
In-Reply-To: <000001c4de99$64e75020$0201a8c0@sjklaptop>
References: <000001c4de99$64e75020$0201a8c0@sjklaptop>
Content-Type: text/plain
Organization: F.W. Davison & Co, Inc.
Message-Id: <1102677153.8605.18.camel@lumpy>
Mime-Version: 1.0
Date: Fri, 10 Dec 2004 06:12:33 -0500
Content-Transfer-Encoding: 7bit


This is probably the bug you're talking about.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29521


On Fri, 2004-12-10 at 04:19, Steve Kirk wrote:
> I have answered one of the points below myself with more testing:
> HttpSessionActivationListener#sessionWillPassivate seems to work slightly
> different to the other Listeners in that its methods are only called when
> they are an object bound to the session is an instance of the
> HttpSessionActivationListener.  The javadocs actually do say this, but I
> didn't take it in at first: "Objects that are bound to a session may listen
> to container events notifying them that sessions will be passivated and that
> session will be activated. A container that migrates session between VMs or
> persists sessions is required to notify all attributes bound to sessions
> implementing HttpSessionActivationListener."
> 
> Thus HttpSessionActivationListener works slightly differently to
> HttpSessionListener for example, because the latter's sessionCreated and
> sessionDestroyed methods are called irrespective of whether they are methods
> of objects bound within the session or not.
> 
> However I'd still appreciate any help that anyone can give on the other
> points below :)
> 
> > -----Original Message-----
> > From: Steve Kirk [mailto:tomcat-user@web-startup.co.uk] 
> > Sent: Friday 10 December 2004 05:50
> > To: 'Tomcat Users List'
> > Subject: RE: sessionS info persistence when restart Tomcat
> > 
> > 
> > 
> > OK well after a few weeks' break from it I've returned to 
> > this problem with
> > fresh eyes, and immediately found out something interesting.
> > 
> > I normally run TC (5.0.28) as a windows service.  So upon 
> > re-reading this
> > thread, Yoav's earlier comment stood out as something I 
> > hadn't checked, so I
> > ran TC using the startup and shutdown scripts instead.  I 
> > have a simple test
> > class which listens for the context/session events and logs 
> > them.  This
> > shows that the following things happen when running from the 
> > DOS scripts,
> > which do not happen when running as a service:
> > 
> > contextDestroyed is called when TC shuts down
> > sessions are serialised to SESSIONS.ser when TC is stopped
> > java.io.NotSerializableException is thrown when a session 
> > object is not
> > serializable
> > 
> > So I guess Yoav's point below from earlier in the thread 
> > could be correct
> > after all - these could be outstanding bugs.  However I couldn't find
> > anything in Bugzilla.
> > 
> > A second point is that 
> > HttpSessionActivationListener#sessionWillPassivate is
> > still not being called, even when start/stopping TC from the 
> > DOS scripts,
> > and whether or not there are any object stored in the session 
> > (I store a
> > simple String in the session for test purposes).  I can't think what's
> > wrong, unless I am using HttpSessionActivationListener 
> > incorrectly?  I have
> > just added it as another interface implemented by my Listener 
> > class along
> > with the other Listener interfaces (HttpSessionListener,
> > HttpSessionAttributeListener, ServletContextListener), is 
> > this correct?
> > 
> > A third point (and perhaps wandering slightly now) is raised 
> > by the logged
> > NotSerializiableException message: 
> > 
> > INFO: Cannot serialize session attribute LOGGED_IN_USER for session
> > 58FD0ECF29BDCEB9DC096C5DF57A1DCC
> > java.io.NotSerializableException: core.servlet.processor.SubmitLogin
> >         at
> > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
> > 
> > this message is odd in that it refers to one of my classes 
> > ("SubmitLogin")
> > which, to my mind, has nothing to do with serialisation 
> > issues.  What does
> > the error message mean when it quotes my class name
> > (core.servlet.processor.SubmitLogin) as the error message?  I 
> > know that this
> > is certainly *not* the class of any object stored in the 
> > session - I have
> > checked this from my event listening class's logs - I write 
> > all the session
> > attributes to the log as each one is added.
> > 
> > Obviously I need to fix my unserialisable session object, but 
> > aside from
> > that, it does seem from all the above as though session events and
> > exceptions are handled differently when TC runs as a windows service
> > compared to from the DOS scripts.  Also I have the problem that
> > sessionWillPassivate still does not seem to be called.
> > 
> > Any help much appreciated :)
> > 
> > > -----Original Message-----
> > > From: Ben Souther [mailto:bsouther@fwdco.com] 
> > > Sent: Friday 05 November 2004 14:52
> > > To: Tomcat Users List
> > > Subject: RE: sessionS info persistence when restart Tomcat
> > > 
> > > 
> > > On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
> > > > Hi,
> > > > Are you running Tomcat as a windows service?  If so 
> > there's an open
> > > > issue with it not calling certain destroy methods on shutdown.
> > > > 
> > > > Yoav Shapira http://www.yoavshapira.com
> > > I believe that issue was with contextDestroyed not being 
> > > called and was
> > > tested under 5.0.8 and 5.5.x and working.
> > > 
> > > > 
> > > > >-----Original Message-----
> > > > >From: Ben Souther [mailto:bsouther@fwdco.com]
> > > > >Sent: Thursday, November 04, 2004 9:22 PM
> > > > >To: Tomcat Users List
> > > > >Subject: RE: sessionS info persistence when restart Tomcat
> > > > >
> > > > >SessionDestroyed shouldn't be called when tomcat shuts 
> > > down. Otherwise,
> > > > >the session wouldn't be valid when it starts up.  I just 
> > > tested with a
> > > > >clean install of 5.0.29 with a similar listener to the one you
> > > > describe.
> > > > >SessionDestroyed was not called when I stopped TC but the 
> > > sessions were
> > > > >still valid when I started it up.  I can give you the war 
> > > file if you
> > > > >like.
> > > > >
> > > > >Do all of the attributes that you're adding to your 
> > > session implement
> > > > >Serializable?
> > > > >
> > > > >> 
> > > 
> > C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
> > > > >>system cannot find the path specified)
> > > > >Does tomcat have sufficient permissions to write to the 
> > > work directory?
> > > > >
> > > > >How are you stopping Tomcat?
> > > > >
> > > > >
> > > > >
> > > > >On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
> > > > >> Following Yoav's earlier comments I've implemented a 
> > basic class
> > > > >> "SessionLogger" that implements HttpSessionListener,
> > > > >> HttpSessionActivationListener, HttpSessionAttributeListener,
> > > > >> ServletContextListener.  It just writes amessages to 
> > stdout using
> > > > >> System.out.println() to log when each event fires, 
> > > including each of
> > > > the
> > > > >> interface events plus instantiation and finalization of 
> > > SessionLogger
> > > > >> itself.  I've configured it in web.xml:
> > > > >>
> > > > >> <listener>
> > > > >> 	
> > <listener-class>core.servlet.SessionLogger</listener-class>
> > > > >> </listener>
> > > > >>
> > > > >> SessionLogger logs its own presence OK when I 
> > instantiate it, and
> > > > happily
> > > > >> logs events as expected on sessions, and session 
> > > attributes.  It logs
> > > > >> context creation but not destruction.  Here's some sample
> > > > catalina.log
> > > > >lines
> > > > >> for starting TC, logging in, logging out, logging in again:
> > > > >>
> > > > >> 2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT:
> > > > initialized
> > > > >> 2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT:
> > > > >sessionCreated,
> > > > >> org.apache.catalina.session.StandardSessionFacade@15ed659
> > > > >> 2004-11-05 00:58:23 StandardContext[/ao]*** SESSION 
> > > ATTRIBUTE EVENT:
> > > > >> attributeAdded, LOGGED_IN_USER, [ID=1]
> > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION 
> > > ATTRIBUTE EVENT:
> > > > >> attributeRemoved, LOGGED_IN_USER, [ID=1]
> > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
> > > > >sessionDestroyed,
> > > > >> org.apache.catalina.session.StandardSessionFacade@15ed659
> > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
> > > > >sessionCreated,
> > > > >> org.apache.catalina.session.StandardSessionFacade@10bbd42
> > > > >> 2004-11-05 00:58:34 StandardContext[/ao]*** SESSION 
> > > ATTRIBUTE EVENT:
> > > > >> attributeAdded, LOGGED_IN_USER, [ID=1]
> > > > >>
> > > > >> However if I then stop TC, I get nothing logged at all 
> > after the
> > > > >> "attributeAdded" event.  The log just shows this as the 
> > > last line:
> > > > >>
> > > > >> 05-Nov-2004 00:03:57 
> > > org.apache.coyote.http11.Http11Protocol pause
> > > > INFO:
> > > > >> Pausing Coyote HTTP/1.1 on http-80
> > > > >>
> > > > >> and there are no loglines to indicate that the
> > > > >> SessionLogger#sessionDestroyed, 
> > SessionLogger#contextDestroyed or
> > > > >> SessionLogger#finalize methods were called.
> > > > >>
> > > > >> So it looks like sessions are working, but something is 
> > > not working
> > > > when
> > > > >TC
> > > > >> stops, and I suspect that this is why my sessions don't 
> > > persist over
> > > > >> restarts.  I've read the docs and how-tos that I can find, plus
> > > > googled
> > > > >> forum stuff on the web.  Does anyone have any insights please?
> > > > >>
> > > > >> PS the above applies whether or not I explicitly add a 
> > > Manager to my
> > > > >context
> > > > >> config.  Note that the standard config files for 5.0.28 do not
> > > > explictly
> > > > >> include a <Manager>, but the docs say that "A Manager 
> > > element MAY be
> > > > >nested
> > > > >> inside a Context component. If it is not included, a 
> > > default Manager
> > > > >> configuration will be created automatically".  I tried adding a
> > > > Manager
> > > > >to
> > > > >> my context as follows just in case following Yoav's 
> > > earlier comments:
> > > > >> <Manager 
> > className="org.apache.catalina.session.StandardManager"
> > > > >> distributable="false" debug="4" pathname="SESSIONS.ser" />
> > > > >> but this made no difference to the behaviour described above.
> > > > >>
> > > > >> Another weird thing: if I trigger a webapp reload by 
> > > rebuilding my
> > > > >warfile
> > > > >> while TC is running, TC complains about the absence of 
> > > SESSIONS.ser -
> > > > it
> > > > >> appears to be trying to persist sessions to the file - 
> > > which it does
> > > > not
> > > > >try
> > > > >> to do when I stop TC.  The log message is:
> > > > >>
> > > > >> 05-Nov-2004 00:23:26 
> > org.apache.catalina.session.StandardManager
> > > > doUnload
> > > > >> SEVERE: IOException while saving persisted sessions:
> > > > >> java.io.FileNotFoundException:
> > > > >> 
> > > 
> > C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
> > > > >system
> > > > >> cannot find the path specified)
> > > > >>
> > > > >> The file does not exist so the message sort of makes 
> > > sense, except
> > > > that
> > > > >this
> > > > >> does not happen if I stop and then start TC again - only 
> > > if a reload
> > > > is
> > > > >> triggered when I rebuild my warfile.
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
> > > > >> > Sent: Thursday 04 November 2004 16:09
> > > > >> > To: Tomcat Users List
> > > > >> > Subject: RE: sessionS info persistence when restart Tomcat
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Hi,
> > > > >> >
> > > > >> > >I had always thought all sessions were lost when the server
> > > > restarts.
> > > > >> > In
> > > > >> > >fact I just tried it and confirmed that (5.0.28).  Are we
> > > > >> > maybe talking
> > > > >> > >about 2 different things?
> > > > >> >
> > > > >> > I think we're talking about the same thing.  Sessions are
> > > > >> > supposed to be
> > > > >> > persisted by default.
> > > > >> >
> > > > >> > >I have nonstandard config (a very sparse server.xml, 
> > > no explicit
> > > > >> > Manager
> > > > >> >
> > > > >> > You need a Manager.  When I said "by default" I mean 
> > out of the
> > > > box,
> > > > >> > i.e. with the default server.xml, which has such a 
> > > Manager IIRC.
> > > > >> >
> > > > >> > >Is this the manager config ref you were talking about?
> > > > >> >
> > > > 
> > >http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
> > > > >> >
> > > > >> > Yeah.
> > > > >> >
> > > > >> > >I just read through it.  If I've understood 
> > > correctly, because my
> > > > >> > Manager
> > > > >> > >is
> > > > >> > >not explicitly configured,
> > > > >> >
> > > > >> > There's a difference between not explicitly configured and
> > > > >> > not declared
> > > > >> > at all.
> > > > >> >
> > > > >> > One way to test this is with an
> > > > >> > HttpSessionListener/HttpSessionActivationListener (one 
> > > listener can
> > > > >> > implement both interfaces and thereby capture all four
> > > > >> > relevant events).
> > > > >> > It's trivial to write one that just prints out information
> > > > >> > when sessions
> > > > >> > are created, destroyed, passivated, and activated.
> > > > >> >
> > > > >> > Yoav
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > This e-mail, including any attachments, is a confidential
> > > > >> > business communication, and may contain information that is
> > > > >> > confidential, proprietary and/or privileged.  This e-mail is
> > > > >> > intended only for the individual(s) to whom it is addressed,
> > > > >> > and may not be saved, copied, printed, disclosed or used by
> > > > >> > anyone else.  If you are not the(an) intended recipient,
> > > > >> > please immediately delete this e-mail from your computer
> > > > >> > system and notify the sender.  Thank you.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > 
> > > 
> > ---------------------------------------------------------------------
> > > > >> > To unsubscribe, e-mail: 
> > > tomcat-user-unsubscribe@jakarta.apache.org
> > > > >> > For additional commands, e-mail:
> > > > tomcat-user-help@jakarta.apache.org
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> 
> > > 
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: 
> > > tomcat-user-unsubscribe@jakarta.apache.org
> > > > >> For additional commands, e-mail: 
> > > tomcat-user-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > 
> > > 
> > >---------------------------------------------------------------------
> > > > >To unsubscribe, e-mail: 
> > tomcat-user-unsubscribe@jakarta.apache.org
> > > > >For additional commands, e-mail: 
> > > tomcat-user-help@jakarta.apache.org
> > > > 
> > > > 
> > > > 
> > > > 
> > > > This e-mail, including any attachments, is a confidential 
> > > business communication, and may contain information that is 
> > > confidential, proprietary and/or privileged.  This e-mail is 
> > > intended only for the individual(s) to whom it is addressed, 
> > > and may not be saved, copied, printed, disclosed or used by 
> > > anyone else.  If you are not the(an) intended recipient, 
> > > please immediately delete this e-mail from your computer 
> > > system and notify the sender.  Thank you.
> > > > 
> > > > 
> > > > 
> > > 
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > tomcat-user-help@jakarta.apache.org
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org