RE: sessionS info persistence when restart Tomcat
Hi, Glad you've solved it. An extra tip on this issue: the commons-lang (http://jakarta.apache.org/commons/lang/) SerializationUtils class is useful in quickly testing whether a complex object graph can be serialized or not. I use it every now and then and it's been great. Hopefully you or others might find it useful in the future. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Steve Kirk [mailto:[EMAIL PROTECTED] >Sent: Friday, December 10, 2004 2:19 PM >To: 'Tomcat Users List' >Subject: RE: sessionS info persistence when restart Tomcat > > >You are of course right ;) I was just experiencing temporary blindness. > >I had overlooked an underlying grandparent class of my User class which was >in the Session; the grandparent contains a reference to its creator, which >is the culprit mentioned in the Exception. This in itself is a nasty that >I >wasn't aware of, so that's 2 things to fix now. > >All solved now :) thanks Yoav/Ben. > >> -Original Message- >> From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >> Sent: Friday 10 December 2004 14:03 >> To: Tomcat Users List >> Subject: RE: sessionS info persistence when restart Tomcat >> >> >> >> Hi, >> Tomcat is not throwing that exception just because it feels >> like it. An >> instance of that class must be reachable in the serialization >> process of >> at least of the session attributes. >> >> Yoav Shapira http://www.yoavshapira.com >> >> >> >-----Original Message- >> >From: Steve Kirk [mailto:[EMAIL PROTECTED] >> >Sent: Friday, December 10, 2004 8:25 AM >> >To: 'Tomcat Users List' >> >Subject: RE: sessionS info persistence when restart Tomcat >> > >> > >> >no. I've checked this by adding more debug code to my SessionLogger >> class >> >(which implements all the Listener interfaces). Every time a session >> event >> >is fired, my listener code lists all the session attribute names and >> values >> >to the log. So when I shutdown TC, the log output looks like this: >> > >> >2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT: >> >sessionWillPassivate, >> >[EMAIL PROTECTED] >> >2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called >> >2004-12-10 12:08:25 StandardContext[/ao]session >> attribute:TEST1=TestString >> >2004-12-10 12:08:25 StandardContext[/ao]session >> >attribute:[EMAIL PROTECTED] >> >2004-12-10 12:08:25 StandardContext[/ao]session >> >attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15 >> >18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRS >> TNAME='sup >> er', >> >L >> >ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADD >> RESS='ao.s >> uper >> >u >> >[EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0 >> >super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1'] >> >2004-12-10 12:08:25 StandardContext[/ao]num attributes:3 >> > >> >So the object named in the log message is not in the >> session. What is >> in >> >the session is core.sql.bean.User, which is a class of my own design >> that >> >basically just has a load of data fields in it (String, Timestamp, >> int). >> >The blurb you can see in the log is the output of the toString() >> method, >> >which just concats the fields together. It's parent and >> subclasses are >> all >> >Serializable. So is the SessionLogger itself. >> > >> >> -Original Message- >> >> From: Ben Souther [mailto:[EMAIL PROTECTED] >> >> Sent: Friday 10 December 2004 13:14 >> >> To: Tomcat Users List >> >> Subject: RE: sessionS info persistence when restart Tomcat >> >> >> >> >> >> > INFO: Cannot serialize session attribute LOGGED_IN_USER >> >> > > for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC >> >> > > java.io.NotSerializableException: >> >> > > core.servlet.processor.SubmitLogin >> >> > > at >> >> >> >> > is certainly *not* the class of any object stored in the >> >> > session - I have >> >> >> >> Do you have a reference to it in any of the objects stored in your >> >> session? >> >> >> >> >>
RE: sessionS info persistence when restart Tomcat
You are of course right ;) I was just experiencing temporary blindness. I had overlooked an underlying grandparent class of my User class which was in the Session; the grandparent contains a reference to its creator, which is the culprit mentioned in the Exception. This in itself is a nasty that I wasn't aware of, so that's 2 things to fix now. All solved now :) thanks Yoav/Ben. > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Friday 10 December 2004 14:03 > To: Tomcat Users List > Subject: RE: sessionS info persistence when restart Tomcat > > > > Hi, > Tomcat is not throwing that exception just because it feels > like it. An > instance of that class must be reachable in the serialization > process of > at least of the session attributes. > > Yoav Shapira http://www.yoavshapira.com > > > >-Original Message- > >From: Steve Kirk [mailto:[EMAIL PROTECTED] > >Sent: Friday, December 10, 2004 8:25 AM > >To: 'Tomcat Users List' > >Subject: RE: sessionS info persistence when restart Tomcat > > > > > >no. I've checked this by adding more debug code to my SessionLogger > class > >(which implements all the Listener interfaces). Every time a session > event > >is fired, my listener code lists all the session attribute names and > values > >to the log. So when I shutdown TC, the log output looks like this: > > > >2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT: > >sessionWillPassivate, > >[EMAIL PROTECTED] > >2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called > >2004-12-10 12:08:25 StandardContext[/ao]session > attribute:TEST1=TestString > >2004-12-10 12:08:25 StandardContext[/ao]session > >attribute:[EMAIL PROTECTED] > >2004-12-10 12:08:25 StandardContext[/ao]session > >attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15 > >18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRS > TNAME='sup > er', > >L > >ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADD > RESS='ao.s > uper > >u > >[EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0 > >super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1'] > >2004-12-10 12:08:25 StandardContext[/ao]num attributes:3 > > > >So the object named in the log message is not in the > session. What is > in > >the session is core.sql.bean.User, which is a class of my own design > that > >basically just has a load of data fields in it (String, Timestamp, > int). > >The blurb you can see in the log is the output of the toString() > method, > >which just concats the fields together. It's parent and > subclasses are > all > >Serializable. So is the SessionLogger itself. > > > >> -Original Message- > >> From: Ben Souther [mailto:[EMAIL PROTECTED] > >> Sent: Friday 10 December 2004 13:14 > >> To: Tomcat Users List > >> Subject: RE: sessionS info persistence when restart Tomcat > >> > >> > >> > INFO: Cannot serialize session attribute LOGGED_IN_USER > >> > > for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC > >> > > java.io.NotSerializableException: > >> > > core.servlet.processor.SubmitLogin > >> > > at > >> > >> > is certainly *not* the class of any object stored in the > >> > session - I have > >> > >> Do you have a reference to it in any of the objects stored in your > >> session? > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > - > >> 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]
RE: sessionS info persistence when restart Tomcat
On Fri, 2004-12-10 at 14:18, Steve Kirk wrote: > You are of course right ;) I was just experiencing temporary blindness. > > I had overlooked an underlying grandparent class of my User class which was > in the Session; the grandparent contains a reference to its creator, which > is the culprit mentioned in the Exception. This in itself is a nasty that I > wasn't aware of, so that's 2 things to fix now. > > All solved now :) thanks Yoav/Ben. Those pesky grandparents ;) Glad you found it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
Hi, Tomcat is not throwing that exception just because it feels like it. An instance of that class must be reachable in the serialization process of at least of the session attributes. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Steve Kirk [mailto:[EMAIL PROTECTED] >Sent: Friday, December 10, 2004 8:25 AM >To: 'Tomcat Users List' >Subject: RE: sessionS info persistence when restart Tomcat > > >no. I've checked this by adding more debug code to my SessionLogger class >(which implements all the Listener interfaces). Every time a session event >is fired, my listener code lists all the session attribute names and values >to the log. So when I shutdown TC, the log output looks like this: > >2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT: >sessionWillPassivate, >[EMAIL PROTECTED] >2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called >2004-12-10 12:08:25 StandardContext[/ao]session attribute:TEST1=TestString >2004-12-10 12:08:25 StandardContext[/ao]session >attribute:[EMAIL PROTECTED] >2004-12-10 12:08:25 StandardContext[/ao]session >attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15 >18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRSTNAME='sup er', >L >ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADDRESS='ao.s uper >u >[EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0 >super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1'] >2004-12-10 12:08:25 StandardContext[/ao]num attributes:3 > >So the object named in the log message is not in the session. What is in >the session is core.sql.bean.User, which is a class of my own design that >basically just has a load of data fields in it (String, Timestamp, int). >The blurb you can see in the log is the output of the toString() method, >which just concats the fields together. It's parent and subclasses are all >Serializable. So is the SessionLogger itself. > >> -Original Message- >> From: Ben Souther [mailto:[EMAIL PROTECTED] >> Sent: Friday 10 December 2004 13:14 >> To: Tomcat Users List >> Subject: RE: sessionS info persistence when restart Tomcat >> >> >> > INFO: Cannot serialize session attribute LOGGED_IN_USER >> > > for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC >> > > java.io.NotSerializableException: >> > > core.servlet.processor.SubmitLogin >> > > at >> >> > is certainly *not* the class of any object stored in the >> > session - I have >> >> Do you have a reference to it in any of the objects stored in your >> session? >> >> >> >> >> >> >> >> >> >> - >> 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]
RE: sessionS info persistence when restart Tomcat
no. I've checked this by adding more debug code to my SessionLogger class (which implements all the Listener interfaces). Every time a session event is fired, my listener code lists all the session attribute names and values to the log. So when I shutdown TC, the log output looks like this: 2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT: sessionWillPassivate, [EMAIL PROTECTED] 2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called 2004-12-10 12:08:25 StandardContext[/ao]session attribute:TEST1=TestString 2004-12-10 12:08:25 StandardContext[/ao]session attribute:[EMAIL PROTECTED] 2004-12-10 12:08:25 StandardContext[/ao]session attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15 18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRSTNAME='super',L ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADDRESS='ao.superu [EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0 super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1'] 2004-12-10 12:08:25 StandardContext[/ao]num attributes:3 So the object named in the log message is not in the session. What is in the session is core.sql.bean.User, which is a class of my own design that basically just has a load of data fields in it (String, Timestamp, int). The blurb you can see in the log is the output of the toString() method, which just concats the fields together. It's parent and subclasses are all Serializable. So is the SessionLogger itself. > -Original Message----- > From: Ben Souther [mailto:[EMAIL PROTECTED] > Sent: Friday 10 December 2004 13:14 > To: Tomcat Users List > Subject: RE: sessionS info persistence when restart Tomcat > > > > INFO: Cannot serialize session attribute LOGGED_IN_USER > > > for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC > > > java.io.NotSerializableException: > > > core.servlet.processor.SubmitLogin > > > at > > > is certainly *not* the class of any object stored in the > > session - I have > > Do you have a reference to it in any of the objects stored in your > session? > > > > > > > > > > - > 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]
RE: sessionS info persistence when restart Tomcat
> INFO: Cannot serialize session attribute LOGGED_IN_USER > > for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC > > java.io.NotSerializableException: > > core.servlet.processor.SubmitLogin > > at > is certainly *not* the class of any object stored in the > session - I have Do you have a reference to it in any of the objects stored in your session? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
Ben Souther said: > > This is probably the bug you're talking about. > http://issues.apache.org/bugzilla/show_bug.cgi?id=29521 > > > Aha. Thanks Ben. That clears up most of it in one go. So it was fixed in 5.0.29 but as far as I can see (from the Jakarta news page and the TC download page) there hasn't been a 5.0.x "final" release since 5.0.28 (which I'm already running). So am I right that if I don't want to use "beta" releases, then to fix this I need to go to 5.5.4? I understand that the switch up to 5.5 brings in the need to make other changes to my code, ISTR logging and some aspects of config are slightly different? Also, can anyone shed any light on my third point below please : > 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
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:[EMAIL PROTECTED] > > 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 > &g
RE: sessionS info persistence when restart Tomcat
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:[EMAIL PROTECTED] > 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:[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. > > > > > > Yo
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:[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, HttpSessionAttributeListene
RE: sessionS info persistence when restart Tomcat
On Fri, 2004-11-05 at 14:53, Mark wrote: > The object stored in the session must implement serializable > interface, right? Or any Java Class object can be stored in the > session and persistence manager will take care how to save and > restore it? It must implement Serializable and any nested objects must implement Serializable. > > --- Ben Souther <[EMAIL PROTECTED]> wrote: > > > > aha. so it looks like it's something I screwed up ;) > > > > > I don't know. I just know that, in my case, the object that I put > > into > > session survives restarts. The easiest way to test things like > > this, for > > me, is to write a small test app and run it on a fresh install of > > Tomcat. If it works there then I start comparing with my app. > > > > > > > out of interest, does contextDestroyed work on that platform? > > > > > It does, I tested on win2k as a service, from the start menu items, > > and > > with the .bat scripts. I also tested on FC2 and RH73. In all cases > > contextDestroyed was called. > > > > -Ben > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > __ > Do you Yahoo!? > Check out the new Yahoo! Front Page. > www.yahoo.com > > > > - > 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]
RE: sessionS info persistence when restart Tomcat
The object stored in the session must implement serializable interface, right? Or any Java Class object can be stored in the session and persistence manager will take care how to save and restore it? --- Ben Souther <[EMAIL PROTECTED]> wrote: > > aha. so it looks like it's something I screwed up ;) > > > I don't know. I just know that, in my case, the object that I put > into > session survives restarts. The easiest way to test things like > this, for > me, is to write a small test app and run it on a fresh install of > Tomcat. If it works there then I start comparing with my app. > > > > out of interest, does contextDestroyed work on that platform? > > > It does, I tested on win2k as a service, from the start menu items, > and > with the .bat scripts. I also tested on FC2 and RH73. In all cases > contextDestroyed was called. > > -Ben > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
> aha. so it looks like it's something I screwed up ;) > I don't know. I just know that, in my case, the object that I put into session survives restarts. The easiest way to test things like this, for me, is to write a small test app and run it on a fresh install of Tomcat. If it works there then I start comparing with my app. > out of interest, does contextDestroyed work on that platform? > It does, I tested on win2k as a service, from the start menu items, and with the .bat scripts. I also tested on FC2 and RH73. In all cases contextDestroyed was called. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
> -Original Message- > From: Ben Souther [mailto:[EMAIL PROTECTED] > Have you tried any of this on a fresh install of Tomcat? No, I last installed fresh a couple of weeks back to upgrade from .27 ; I deleted the whole CATALINA_HOME dir first. I then replaced conf/server.xml and conf/web.xml, and installed my warfiles. > I think you mentioned that you have made changes to the Persistance > Manaager in server.xml. sort of. I have modified server.xml, although having said that, there is no Manager by default in server.xml, persistent or not, as far as I can tell. My server.xml is very sparse: > Try downloading and installing a fresh instance and run the > test again. > There is a similar test war file (attachment) that looks tests the > contextCreated/Destroyed methods here: > http://issues.apache.org/bugzilla/show_bug.cgi?id=29521 OK, will do next week but out of time for that today. > For what it's worth. Serialization of sessions is working for me with > 5.0.28 running as an NT Service on windows. aha. so it looks like it's something I screwed up ;) out of interest, does contextDestroyed work on that platform? > -Ben > > On Fri, 2004-11-05 at 11:20, Steve Kirk wrote: > > Thanks Ben, have looked at your war, and my test code > covers the same as > > yours plus some of the other Listener events. The > sessionCreated and > > sessionDestroyed events work fine on my code (5.0.28). The > problem is that > > the other events I mentioned are not called - e.g. contextDestroyed. > > > > > If your object (or any of the objects contained within it) are not > > > serializable) tomcat will quietly not save it. > > > > ok that's interesting and perhaps a little surprising given > that the docs > > say that they MUST be. I've also tried adding the > distributable attribute > > to the webapp as indicated here > > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager > .html#Restart% > > 20Persistence > > to see if that causes stricter behaviour (e.g. throwing an > exception when TC > > tries to serialize session objects), but this appears to > make no difference > > in my situation. > > > > > try creating a real simple object that implements > Serializable and see > > > if it survives a restart. > > > > In effect I have already done that by restarting TC, then > browsing webapp > > pages as a user that does not log in. In this case I do > not assign any > > objects to the session (I have checked this using > session.getAttributeNames > > in my SessionLogger to check that there are none). Even in > this case TC > > does not serialize to SESSIONS.ser on shutdown. So I don't > think that the > > problem is serialisability? > > > > Also, still can't work out why SESSIONS.ser is only > accessed when a new > > warfile causes a reload and not otherwise. > > > > > -Original Message- > > > From: Ben Souther [mailto:[EMAIL PROTECTED] > > > Sent: Friday 05 November 2004 15:08 > > > To: Tomcat Users List > > > Subject: RE: sessionS info persistence when restart Tomcat > > > > > > > > > On Fri, 2004-11-05 at 09:06, Steve Kirk wrote: > > > > > SessionDestroyed shouldn't be called when tomcat shuts down. > > > > > > > > good point. doh! but if I've understood correctly, > > > shouldn't other methods > > > > of my SessionLogger be called? namely sessionWillPassivate, > > > > contextDestroyed (and possibly finalize although I'm not > > > 100% confident of > > > > that). > > > contextDestroyed does get called when you shut down tomcat. I > > > don't know > > > about sessionWillPassivate. > > > > > > > > > > > > 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. > > > > > > > > yes please. email it to me off list if you prefer. > > > > > > You can grab it here: > > > http://www.souther.us/sessionTest.war > > > > > > I ran it
RE: sessionS info persistence when restart Tomcat
Have you tried any of this on a fresh install of Tomcat? I think you mentioned that you have made changes to the Persistance Manaager in server.xml. Try downloading and installing a fresh instance and run the test again. There is a similar test war file (attachment) that looks tests the contextCreated/Destroyed methods here: http://issues.apache.org/bugzilla/show_bug.cgi?id=29521 For what it's worth. Serialization of sessions is working for me with 5.0.28 running as an NT Service on windows. -Ben On Fri, 2004-11-05 at 11:20, Steve Kirk wrote: > Thanks Ben, have looked at your war, and my test code covers the same as > yours plus some of the other Listener events. The sessionCreated and > sessionDestroyed events work fine on my code (5.0.28). The problem is that > the other events I mentioned are not called - e.g. contextDestroyed. > > > If your object (or any of the objects contained within it) are not > > serializable) tomcat will quietly not save it. > > ok that's interesting and perhaps a little surprising given that the docs > say that they MUST be. I've also tried adding the distributable attribute > to the webapp as indicated here > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html#Restart% > 20Persistence > to see if that causes stricter behaviour (e.g. throwing an exception when TC > tries to serialize session objects), but this appears to make no difference > in my situation. > > > try creating a real simple object that implements Serializable and see > > if it survives a restart. > > In effect I have already done that by restarting TC, then browsing webapp > pages as a user that does not log in. In this case I do not assign any > objects to the session (I have checked this using session.getAttributeNames > in my SessionLogger to check that there are none). Even in this case TC > does not serialize to SESSIONS.ser on shutdown. So I don't think that the > problem is serialisability? > > Also, still can't work out why SESSIONS.ser is only accessed when a new > warfile causes a reload and not otherwise. > > > -Original Message----- > > From: Ben Souther [mailto:[EMAIL PROTECTED] > > Sent: Friday 05 November 2004 15:08 > > To: Tomcat Users List > > Subject: RE: sessionS info persistence when restart Tomcat > > > > > > On Fri, 2004-11-05 at 09:06, Steve Kirk wrote: > > > > SessionDestroyed shouldn't be called when tomcat shuts down. > > > > > > good point. doh! but if I've understood correctly, > > shouldn't other methods > > > of my SessionLogger be called? namely sessionWillPassivate, > > > contextDestroyed (and possibly finalize although I'm not > > 100% confident of > > > that). > > contextDestroyed does get called when you shut down tomcat. I > > don't know > > about sessionWillPassivate. > > > > > > > > > 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. > > > > > > yes please. email it to me off list if you prefer. > > > > You can grab it here: > > http://www.souther.us/sessionTest.war > > > > I ran it in a clean install of TC5.0.29. > > There are two jsps and a sessionListener. > > test.jsp shows you the current sessionID. > > kill.jsp invalidates the session. > > The session listener prints to stdout (catalina.out) > > when a session is created or destroyed. > > > > I was able to stop and restart TC and maintain the same session. > > sessionDestroyed was not called. > > > > You could easily add to it to test for sessionWillPassivate(). > > > > > > > > > > > > > > > > > Do all of the attributes that you're adding to your > > session implement > > > > Serializable? > > > > > > I did spot that issue late on just before my last post. So > > I checked and > > > only one object is ever stored in the session - a "User" > > class of my own. > > > Its fields are all of type String, java.sql.Timestamp or > > int. I added > > > "implements Serializable" to it (I think this is all that > > was required?) but > > > this made no difference. Also, I have tried stopping TC > > when a session h
RE: sessionS info persistence when restart Tomcat
Thanks Ben, have looked at your war, and my test code covers the same as yours plus some of the other Listener events. The sessionCreated and sessionDestroyed events work fine on my code (5.0.28). The problem is that the other events I mentioned are not called - e.g. contextDestroyed. > If your object (or any of the objects contained within it) are not > serializable) tomcat will quietly not save it. ok that's interesting and perhaps a little surprising given that the docs say that they MUST be. I've also tried adding the distributable attribute to the webapp as indicated here http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html#Restart% 20Persistence to see if that causes stricter behaviour (e.g. throwing an exception when TC tries to serialize session objects), but this appears to make no difference in my situation. > try creating a real simple object that implements Serializable and see > if it survives a restart. In effect I have already done that by restarting TC, then browsing webapp pages as a user that does not log in. In this case I do not assign any objects to the session (I have checked this using session.getAttributeNames in my SessionLogger to check that there are none). Even in this case TC does not serialize to SESSIONS.ser on shutdown. So I don't think that the problem is serialisability? Also, still can't work out why SESSIONS.ser is only accessed when a new warfile causes a reload and not otherwise. > -Original Message- > From: Ben Souther [mailto:[EMAIL PROTECTED] > Sent: Friday 05 November 2004 15:08 > To: Tomcat Users List > Subject: RE: sessionS info persistence when restart Tomcat > > > On Fri, 2004-11-05 at 09:06, Steve Kirk wrote: > > > SessionDestroyed shouldn't be called when tomcat shuts down. > > > > good point. doh! but if I've understood correctly, > shouldn't other methods > > of my SessionLogger be called? namely sessionWillPassivate, > > contextDestroyed (and possibly finalize although I'm not > 100% confident of > > that). > contextDestroyed does get called when you shut down tomcat. I > don't know > about sessionWillPassivate. > > > > > > 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. > > > > yes please. email it to me off list if you prefer. > > You can grab it here: > http://www.souther.us/sessionTest.war > > I ran it in a clean install of TC5.0.29. > There are two jsps and a sessionListener. > test.jsp shows you the current sessionID. > kill.jsp invalidates the session. > The session listener prints to stdout (catalina.out) > when a session is created or destroyed. > > I was able to stop and restart TC and maintain the same session. > sessionDestroyed was not called. > > You could easily add to it to test for sessionWillPassivate(). > > > > > > > > > > Do all of the attributes that you're adding to your > session implement > > > Serializable? > > > > I did spot that issue late on just before my last post. So > I checked and > > only one object is ever stored in the session - a "User" > class of my own. > > Its fields are all of type String, java.sql.Timestamp or > int. I added > > "implements Serializable" to it (I think this is all that > was required?) but > > this made no difference. Also, I have tried stopping TC > when a session has > > been created but *no* attributes have been added to it, and > the problem is > > the same. > > > > In any case though, if serialisation was the problem, > shouldn't I see some > > kind of error message from TC along the lines that it > cannot serialise an > > object in a session? Also I can't work out why it only > complains that it > > can't find SESSIONS.ser when it reloads the webapp? > > > If your object (or any of the objects contained within it) are not > serializable) tomcat will quietly not save it. > > try creating a real simple object that implements Serializable and see > if it survives a restart. > > -Ben > > > > > - > 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]
RE: sessionS info persistence when restart Tomcat
On Fri, 2004-11-05 at 09:06, Steve Kirk wrote: > > SessionDestroyed shouldn't be called when tomcat shuts down. > > good point. doh! but if I've understood correctly, shouldn't other methods > of my SessionLogger be called? namely sessionWillPassivate, > contextDestroyed (and possibly finalize although I'm not 100% confident of > that). contextDestroyed does get called when you shut down tomcat. I don't know about sessionWillPassivate. > > > 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. > > yes please. email it to me off list if you prefer. You can grab it here: http://www.souther.us/sessionTest.war I ran it in a clean install of TC5.0.29. There are two jsps and a sessionListener. test.jsp shows you the current sessionID. kill.jsp invalidates the session. The session listener prints to stdout (catalina.out) when a session is created or destroyed. I was able to stop and restart TC and maintain the same session. sessionDestroyed was not called. You could easily add to it to test for sessionWillPassivate(). > > > Do all of the attributes that you're adding to your session implement > > Serializable? > > I did spot that issue late on just before my last post. So I checked and > only one object is ever stored in the session - a "User" class of my own. > Its fields are all of type String, java.sql.Timestamp or int. I added > "implements Serializable" to it (I think this is all that was required?) but > this made no difference. Also, I have tried stopping TC when a session has > been created but *no* attributes have been added to it, and the problem is > the same. > > In any case though, if serialisation was the problem, shouldn't I see some > kind of error message from TC along the lines that it cannot serialise an > object in a session? Also I can't work out why it only complains that it > can't find SESSIONS.ser when it reloads the webapp? > If your object (or any of the objects contained within it) are not serializable) tomcat will quietly not save it. try creating a real simple object that implements Serializable and see if it survives a restart. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
OK well to be clear yes I'm running 5.0.28 on JDK 1.4.2_05 on Win2k SP4 > -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: > > >> > > >> > > >> core.servlet.SessionLogger > > >> > > >> > > >> 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 > > &
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: > >> > >> > >>core.servlet.SessionLogger > >> > >> > >> 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 , 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: > >
RE: sessionS info persistence when restart Tomcat
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: > > > 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.s > er (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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sessionS info persistence when restart Tomcat
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: >> >> >> core.servlet.SessionLogger >> >> >> 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 , 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: >> > 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.FileNotFoundExce
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: > > > core.servlet.SessionLogger > > > 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 , 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: > 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 ju
RE: sessionS info persistence when restart Tomcat
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: core.servlet.SessionLogger 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 , 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: 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 activa
RE: sessionS info persistence when restart Tomcat
So it's a documentation bug then :-) --- "Shapira, Yoav" <[EMAIL PROTECTED]> wrote: > > Hi, > Hmm, I think that note is very old. It was probably copied over > from > Tomcat 4. The PersistentManager hasn't had any bugs filed against > it > for months at least (and it's been around for years now) so it's > probably in good shape. > > Yoav Shapira http://www.yoavshapira.com > > > >-Original Message- > >From: Mark [mailto:[EMAIL PROTECTED] > >Sent: Thursday, November 04, 2004 2:14 PM > >To: Tomcat Users List > >Subject: RE: sessionS info persistence when restart Tomcat > > > >Here some info I found: > >http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > > > >but...: > >--cut - > >Persistent Manager Implementation > > > >WARNING - Use of this Manager implementation has not been > thoroughly > >tested, and should be considered experimental! > > > > end cut -- > > > >Can anybody confirm what is a status for Persistent Manager in > Tomcat > >5.0.X? is it stable, is it safe to use in production and if not > what > >are other options. > > > >and here another link with detailed info on Persistent Manager: > >http://www.devx.com/assets/download/6264.pdf > > > >Mark. > > > > > >--- Steve Kirk <[EMAIL PROTECTED]> wrote: > > > >> 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 have nonstandard config (a very sparse server.xml, no explicit > >> Manager > >> configured in server/web/context xml), and I do not use TC > >> authentication/realms, I just use request.getSession(true) and > rely > >> on > >> cookies to track users. After a restart, the webapp has lost > track > >> of users > >> that were tracked right up to the restart. > >> > >> Is this the manager config ref you were talking about? > >> > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > >> > >> > >> I just read through it. If I've understood correctly, because > my > >> Manager is > >> not explicitly configured, I have a default session manager > >> implicitly. I > >> stopped the server and looked for the serialised session file > under > >> /work > >> but just found the usual .java and .class files and one file > called > >> tldCache.ser, no sessions.ser or anything that looks like a > >> serialised > >> session file. > >> > >> > -Original Message- > >> > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > >> > Sent: Thursday 04 November 2004 15:07 > >> > To: Tomcat Users List > >> > Subject: RE: sessionS info persistence when restart Tomcat > >> > > >> > > >> > > >> > Hi, > >> > Tomcat persists and reloads sessions on restart by default. > And > >> the > >> > default session timeout is 30 minutes. So you shouldn't have > to > >> do > >> > anything. > >> > > >> > Check out the Manager configuration reference (not the Manager > >> webapp) > >> > for more details and settings you can modify in this area. > >> > > >> > Yoav Shapira http://www.yoavshapira.com > >> > > >> > > >> > >-Original Message- > >> > >From: Mark [mailto:[EMAIL PROTECTED] > >> > >Sent: Thursday, November 04, 2004 10:04 AM > >> > >To: [EMAIL PROTECTED] > >> > >Subject: sessionS info persistence when restart Tomcat > >> > > > >> > >Hi, > >> > > > >> > >Is it possible to save sessions info, so when Tomcat restarts > >> all > >> > >previously active sessions will be loaded. > >> > > > >> > >I'm trying to prevent user's re-login when Tomcat goes down > for > >> short > >> > >period (5-15 minutes) of time. > >> > > > >> > >Thanks, > >> > >Mark > >> > > > >> > > > >> > > > >> > >__ > >> > >Do you Yahoo!? > >> > >Check out the new Yahoo! Front Page. > &g
RE: sessionS info persistence when restart Tomcat
Hi, Hmm, I think that note is very old. It was probably copied over from Tomcat 4. The PersistentManager hasn't had any bugs filed against it for months at least (and it's been around for years now) so it's probably in good shape. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Mark [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 04, 2004 2:14 PM >To: Tomcat Users List >Subject: RE: sessionS info persistence when restart Tomcat > >Here some info I found: >http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > >but...: >--cut - >Persistent Manager Implementation > >WARNING - Use of this Manager implementation has not been thoroughly >tested, and should be considered experimental! > > end cut -- > >Can anybody confirm what is a status for Persistent Manager in Tomcat >5.0.X? is it stable, is it safe to use in production and if not what >are other options. > >and here another link with detailed info on Persistent Manager: >http://www.devx.com/assets/download/6264.pdf > >Mark. > > >--- Steve Kirk <[EMAIL PROTECTED]> wrote: > >> 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 have nonstandard config (a very sparse server.xml, no explicit >> Manager >> configured in server/web/context xml), and I do not use TC >> authentication/realms, I just use request.getSession(true) and rely >> on >> cookies to track users. After a restart, the webapp has lost track >> of users >> that were tracked right up to the restart. >> >> Is this the manager config ref you were talking about? >> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html >> >> >> I just read through it. If I've understood correctly, because my >> Manager is >> not explicitly configured, I have a default session manager >> implicitly. I >> stopped the server and looked for the serialised session file under >> /work >> but just found the usual .java and .class files and one file called >> tldCache.ser, no sessions.ser or anything that looks like a >> serialised >> session file. >> >> > -Original Message- >> > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >> > Sent: Thursday 04 November 2004 15:07 >> > To: Tomcat Users List >> > Subject: RE: sessionS info persistence when restart Tomcat >> > >> > >> > >> > Hi, >> > Tomcat persists and reloads sessions on restart by default. And >> the >> > default session timeout is 30 minutes. So you shouldn't have to >> do >> > anything. >> > >> > Check out the Manager configuration reference (not the Manager >> webapp) >> > for more details and settings you can modify in this area. >> > >> > Yoav Shapira http://www.yoavshapira.com >> > >> > >> > >-Original Message- >> > >From: Mark [mailto:[EMAIL PROTECTED] >> > >Sent: Thursday, November 04, 2004 10:04 AM >> > >To: [EMAIL PROTECTED] >> > >Subject: sessionS info persistence when restart Tomcat >> > > >> > >Hi, >> > > >> > >Is it possible to save sessions info, so when Tomcat restarts >> all >> > >previously active sessions will be loaded. >> > > >> > >I'm trying to prevent user's re-login when Tomcat goes down for >> short >> > >period (5-15 minutes) of time. >> > > >> > >Thanks, >> > >Mark >> > > >> > > >> > > >> > >__ >> > >Do you Yahoo!? >> > >Check out the new Yahoo! Front Page. >> > >www.yahoo.com >> > > >> > > >> > > >> > >> >>- >> > >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 use
RE: sessionS info persistence when restart Tomcat
Here some info I found: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html but...: --cut - Persistent Manager Implementation WARNING - Use of this Manager implementation has not been thoroughly tested, and should be considered experimental! end cut -- Can anybody confirm what is a status for Persistent Manager in Tomcat 5.0.X? is it stable, is it safe to use in production and if not what are other options. and here another link with detailed info on Persistent Manager: http://www.devx.com/assets/download/6264.pdf Mark. --- Steve Kirk <[EMAIL PROTECTED]> wrote: > 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 have nonstandard config (a very sparse server.xml, no explicit > Manager > configured in server/web/context xml), and I do not use TC > authentication/realms, I just use request.getSession(true) and rely > on > cookies to track users. After a restart, the webapp has lost track > of users > that were tracked right up to the restart. > > Is this the manager config ref you were talking about? > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > > > I just read through it. If I've understood correctly, because my > Manager is > not explicitly configured, I have a default session manager > implicitly. I > stopped the server and looked for the serialised session file under > /work > but just found the usual .java and .class files and one file called > tldCache.ser, no sessions.ser or anything that looks like a > serialised > session file. > > > -Original Message- > > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > > Sent: Thursday 04 November 2004 15:07 > > To: Tomcat Users List > > Subject: RE: sessionS info persistence when restart Tomcat > > > > > > > > Hi, > > Tomcat persists and reloads sessions on restart by default. And > the > > default session timeout is 30 minutes. So you shouldn't have to > do > > anything. > > > > Check out the Manager configuration reference (not the Manager > webapp) > > for more details and settings you can modify in this area. > > > > Yoav Shapira http://www.yoavshapira.com > > > > > > >-Original Message- > > >From: Mark [mailto:[EMAIL PROTECTED] > > >Sent: Thursday, November 04, 2004 10:04 AM > > >To: [EMAIL PROTECTED] > > >Subject: sessionS info persistence when restart Tomcat > > > > > >Hi, > > > > > >Is it possible to save sessions info, so when Tomcat restarts > all > > >previously active sessions will be loaded. > > > > > >I'm trying to prevent user's re-login when Tomcat goes down for > short > > >period (5-15 minutes) of time. > > > > > >Thanks, > > >Mark > > > > > > > > > > > >__ > > >Do you Yahoo!? > > >Check out the new Yahoo! Front Page. > > >www.yahoo.com > > > > > > > > > > > > >- > > >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] > > __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: sessionS info persistence when restart Tomcat
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 have nonstandard config (a very sparse server.xml, no explicit Manager configured in server/web/context xml), and I do not use TC authentication/realms, I just use request.getSession(true) and rely on cookies to track users. After a restart, the webapp has lost track of users that were tracked right up to the restart. Is this the manager config ref you were talking about? http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html I just read through it. If I've understood correctly, because my Manager is not explicitly configured, I have a default session manager implicitly. I stopped the server and looked for the serialised session file under /work but just found the usual .java and .class files and one file called tldCache.ser, no sessions.ser or anything that looks like a serialised session file. > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Thursday 04 November 2004 15:07 > To: Tomcat Users List > Subject: RE: sessionS info persistence when restart Tomcat > > > > Hi, > Tomcat persists and reloads sessions on restart by default. And the > default session timeout is 30 minutes. So you shouldn't have to do > anything. > > Check out the Manager configuration reference (not the Manager webapp) > for more details and settings you can modify in this area. > > Yoav Shapira http://www.yoavshapira.com > > > >-Original Message- > >From: Mark [mailto:[EMAIL PROTECTED] > >Sent: Thursday, November 04, 2004 10:04 AM > >To: [EMAIL PROTECTED] > >Subject: sessionS info persistence when restart Tomcat > > > >Hi, > > > >Is it possible to save sessions info, so when Tomcat restarts all > >previously active sessions will be loaded. > > > >I'm trying to prevent user's re-login when Tomcat goes down for short > >period (5-15 minutes) of time. > > > >Thanks, > >Mark > > > > > > > >__ > >Do you Yahoo!? > >Check out the new Yahoo! Front Page. > >www.yahoo.com > > > > > > > >- > >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]
RE: sessionS info persistence when restart Tomcat
Hi, Tomcat persists and reloads sessions on restart by default. And the default session timeout is 30 minutes. So you shouldn't have to do anything. Check out the Manager configuration reference (not the Manager webapp) for more details and settings you can modify in this area. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Mark [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 04, 2004 10:04 AM >To: [EMAIL PROTECTED] >Subject: sessionS info persistence when restart Tomcat > >Hi, > >Is it possible to save sessions info, so when Tomcat restarts all >previously active sessions will be loaded. > >I'm trying to prevent user's re-login when Tomcat goes down for short >period (5-15 minutes) of time. > >Thanks, >Mark > > > >__ >Do you Yahoo!? >Check out the new Yahoo! Front Page. >www.yahoo.com > > > >- >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]