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:[EMAIL PROTECTED]
> 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:[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]
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]
