> Hmm, that's a bit concerning. I found your lack of faith disturbing, you must believe in the force luke, especially when you wish to pay $0 for the software :)
Here is what is happening in on context reload, there is a setting in the server.xml called "expireSessionsOnShutdown", if this is set to false, the sessions in that node wont get expired and survive the context reload, hence the ClassCastException getting thrown since your class is reloaded but the session remains in memory. Turning expireSessionsOnShutdown to true will expire the sessions and propagate the message to the other nodes. I realize that this behavior is a little bit odd, perhaps even screwed up, and I will modify it to function this way: 1. expireSessionsOnShutdown="true" - will expire the sessions in the node and propage the expire message to the other nodes 2. expireSessionsOnShutdown="false" - will expire the sessions in the local node, but not in the other cluster nodes. The bug described in this thread really comes into play when you reload context, which I never do, hence I forgot to account for that scenario. I will put in a fix for this into Tomcat 5.5 right away, and 5.0.x when time frees up. Filip -----Original Message----- From: Matthew Stone [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 3:39 PM To: Tomcat Users List Subject: Re: Session problems with cluster "Filip Hanik (lists)" wrote: > What's concerning? "the session actually randomly loses data sometimes" > > To set the record straight, I have not worked with context reloads, so I > don't know what changed from 5.0.25 to 5.0.28. > But I do know this, don't expect clustering to work with nodes popping in > and out all the time. Yes session replication is a nifty thing, but if you > abuse it its going to not go over well, just like anything else. "don't expect clustering to work"? > > Let me know when you have a good test case, as all my tests are coming > through just fine Interesting. There's not really anything in the test to change. Just putting an object in the session and getting out after a context restart. Well, I appreciate the time. Thanks, Matthew > > I will not be able to work on the context reload problem anytime soon, so > don't hold your breath. > > Brantley, if you read this, make sure you populate your bug report with all > info, OS JDK version, etc > > Filip > > -----Original Message----- > From: Matthew Stone [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 19, 2004 11:15 AM > To: Tomcat Users List > Subject: Re: Session problems with cluster > > Hmm, that's a bit concerning. > > Brantley Hobbs wrote: > > > Matt, > > > > We've seen a similar problem with our cluster. > > > > First off, let me say that I'm the person that filed bug #31495, so > > we've been struggling with clustering for a while now. > > > > In our case, we've actually stored a string as a session attribute on a > > page, and then keep reloading the page, appending to the string with > > each reload (e.g., myString += "-1" should produce "-1-1-1-1-1-1..." > > with the string growing longer with each reload). What we've found is > > that the session actually randomly loses data sometimes (i.e., the > > string doesn't get appended). We're not at the point yet to be able to > > identify the problem well enough to file a bug, but that may be coming > > soon. The problem does not happen at all when there is only one machine > > in the "cluster". > > > > This might not seem on the surface to be the same problem, but it seems > > suspicious that you're also noticing data consistency issues. > > > > Filip, as soon as we can we will get some test code together that > > reproduces the problem and get it to you. Is it appropriate to send it > > directly to you? > > > > Thanks, > > Brantley Hobbs > > > > > -----Original Message----- > > > From: Matthew Stone [mailto:[EMAIL PROTECTED] > > > Sent: Monday, October 18, 2004 6:23 PM > > > To: Tomcat Users List > > > Subject: Re: Session problems with cluster > > > > > > Filip, > > > > > > I discovered this when I had one node in the cluster. With no other > > nodes > > > to receive a session from, I expected the session to be > > > empty. Is the session intended to survive reloads in this case? I > > would > > > guess not, just because of the complexities involved with the > > > > > > class definitions. > > > > > > This code should be enough to cause the problem after a stop and start > > of > > > the context. > > > > > > :test.jsp > > > <html> > > > <% > > > Object obj = request.getSession ().getAttribute ("my_object"); > > > > > > if (obj == null) { > > > out.println("MyObject was null. Adding instance to session, please > > > start and stop context.<br>"); > > > request.getSession ().setAttribute ("my_object", new > > testpkg.MyObject > > > ()); > > > } else { > > > out.println ("<li>MyObject was in session"); > > > out.println ("<li>Do class names match: " + (obj.getClass > > ().getName > > > ().equals (testpkg.MyObject.class.getName ()))); > > > out.println ("<li>Are objects assignable: " + (obj instanceof > > > testpkg.MyObject) + "<br>"); > > > > > > try { > > > testpkg.MyObject o = (testpkg.MyObject) request.getSession > > > ().getAttribute ("my_object"); > > > } catch (ClassCastException e) { > > > out.println ("<li>" + e); > > > } > > > } > > > > > > %> > > > </html> > > > > > > :MyObject.java > > > package testpkg; > > > > > > public class MyObject implements java.io.Serializable { > > > public int i = 0; > > > } > > > > > > web.xml > > > > > > <?xml version="1.0" encoding="ISO-8859-1"?> > > > <!DOCTYPE web-app > > > PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" > > > "http://java.sun.com/dtd/web-app_2_3.dtd";> > > > > > > <web-app> > > > <display-name>Test</display-name> > > > > > > <distributable/> > > > </web-app> > > > > > > > > > - Used all the packaged cluster settings. > > > > > > Thanks, > > > Matthew > > > > > > > > > Filip Hanik - Dev wrote: > > > > > > > >I'm expecting a null from > > > > >the following line > > > > > > > > No, you would not expect null. The session replication mechanism is > > > supposed to survive context reloads. > > > > But you should not be getting a ClassCastException, if you are I > > would > > > love for you to submit a test case. > > > > > > > > When a context is reloaded, it will startup again, at which point > > the > > > manager will request the state from another server. This data > > > > comes over serialized and is reloaded by the new classloader, hence > > you > > > shouldn't get ClassCastExceptions, > > > > > > > > the only way you would get class cast exceptions is if you actually > > > recompiled the class on one of your servers. > > > > > > > > Due to busy work schedule, I haven't had a chance to fix the context > > > reload, I only recently found out (same way you did) that > > > > context reload was broken. > > > > > > > > Filip > > > > > > > > ----- Original Message ----- > > > > From: "Matthew Stone" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Monday, October 18, 2004 2:09 PM > > > > Subject: Session problems with cluster > > > > > > > > When I restart the context of a clustered node the session doesnt > > seem > > > > to be cleared. After I restart the context, I'm expecting a null > > from > > > > the following line but I'm getting a ClassCastException because of > > the > > > > different class loaders that loaded MyObject. > > > > > > > > MyObject obj = (MyObject) request.getSession ().getAttribute > > > > ("my_object"); > > > > > > > > I'm using 5.0.25 because I was running into bug 31495 "Context > > reload > > > > causes ClusterManager to stop operating" in version 5.0.28. > > > > > > > > Does 5.0.29 address this? I didn't see that the bug was closed. > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > --------------------------------------------------------------------- > > 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] > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 > > --------------------------------------------------------------------- > 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] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
