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 >-----Original Message----- >From: Ben Souther [mailto:[EMAIL PROTECTED] >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, >> [EMAIL PROTECTED] >> 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, >> [EMAIL PROTECTED] >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: >sessionCreated, >> [EMAIL PROTECTED] >> 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:[EMAIL PROTECTED] >> > 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: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
