tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik - Dev" <devli...@hanik.com>
Subject Re: Session problems with cluster
Date Tue, 19 Oct 2004 13:24:15 GMT
feel free to send it directly to me, fhanik at apache dot org

Filip

----- Original Message ----- 
From: "Brantley Hobbs" <bhobbs@itos.uga.edu>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Sent: Tuesday, October 19, 2004 7:23 AM
Subject: RE: Session problems with cluster


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:mstone@bidnask.com]
> 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" <mstone@bidnask.com>
> > To: <tomcat-user@jakarta.apache.org>
> > 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: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message