Filip, Great ... Thanks.
Matthew "Filip Hanik (lists)" wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
