"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]
