Re: Session problems with cluster
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, Octo
RE: Session problems with cluster
oh, I forgot to mention, useDirtyFlag is only used with
SimpleTcpReplicationManager, cause there is no AOP code that could detect
that objects inside the session have changed
Filip
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 6:16 PM
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: RE: Session problems with cluster
hi Ivan,
it took me a while to figure out what was going on.
its a coding/configuration problem on your part. Your code would have worked
if you had configured "SimpleTcpReplicationManager" with
useDirtyFlag="false" instead of DeltaManager.
to fix your code, you would need to do this
replace:
((List)session.getAttribute("list")).add(new String("foo"));
with:
((List)session.getAttribute("list")).add(new String("foo"));
session.setAttribute("list",session.getAttribute("list"));
and try again,
the delta manager only replicates session delta's, and the only way to keep
track of deltas are when the code calls setAttribute or removeAttribute
Filip
-Original Message-
From: Ivan Vasquez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:13 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
Filip, here is a concrete case that you may find interesting. It's a
very simple JSP that stores a List in the session, adds an item to it on
every submission and then checks to see if there have been lost items
since the previous request.
To reproduce the error, just deploy in a cluster it and visit the page
(index.jsp) Our tests are consistent in that, the moment any other
clustered application is visited, this page will notify that it has lost
items.
Our main intention is to help identify the problem, because we believe!
Tomcat 5.0.25 (5.0.28 has the reload problem, so we downgraded)
JDK 1.4.2
Cluster config:
index.jsp
---
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
<%@ page import="java.util.*" %>
<%@ page import="java.net.*" %>
function submit_frm() {
if (document.testform.listSize.value !=
document.testform.listPrevSize.value)
alert('List out of sync: Reported size = ' +
document.testform.listSize.value + ', expected = ' +
document.testform.listPrevSize.value);
else
document.testform.submit();
}
self.setTimeout('submit_frm()', 200);
<%
out.println(java.net.InetAddress.getLocalHost().getHostName()); %>
SessionID ${pageContext.session.id}
<%
// Initialize list on first load or when no parameters
are passed
if (session.getAttribute("list") == null ||
request.getParameter("listSize") == null) {
out.println("List is null,
creating");
session.setAttribute("list", new ArrayList());
}
out.println("Collection Size");
((List)session.getAttribute("list")).add(new
String("foo"));
%>
List size in session
Previous list size + 1:
Restart
---
end index.jsp
Thank you
Ivan
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:39 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
> 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 neve
RE: Session problems with cluster
hi Ivan,
it took me a while to figure out what was going on.
its a coding/configuration problem on your part. Your code would have worked
if you had configured "SimpleTcpReplicationManager" with
useDirtyFlag="false" instead of DeltaManager.
to fix your code, you would need to do this
replace:
((List)session.getAttribute("list")).add(new String("foo"));
with:
((List)session.getAttribute("list")).add(new String("foo"));
session.setAttribute("list",session.getAttribute("list"));
and try again,
the delta manager only replicates session delta's, and the only way to keep
track of deltas are when the code calls setAttribute or removeAttribute
Filip
-Original Message-
From: Ivan Vasquez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:13 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
Filip, here is a concrete case that you may find interesting. It's a
very simple JSP that stores a List in the session, adds an item to it on
every submission and then checks to see if there have been lost items
since the previous request.
To reproduce the error, just deploy in a cluster it and visit the page
(index.jsp) Our tests are consistent in that, the moment any other
clustered application is visited, this page will notify that it has lost
items.
Our main intention is to help identify the problem, because we believe!
Tomcat 5.0.25 (5.0.28 has the reload problem, so we downgraded)
JDK 1.4.2
Cluster config:
index.jsp
---
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
<%@ page import="java.util.*" %>
<%@ page import="java.net.*" %>
function submit_frm() {
if (document.testform.listSize.value !=
document.testform.listPrevSize.value)
alert('List out of sync: Reported size = ' +
document.testform.listSize.value + ', expected = ' +
document.testform.listPrevSize.value);
else
document.testform.submit();
}
self.setTimeout('submit_frm()', 200);
<%
out.println(java.net.InetAddress.getLocalHost().getHostName()); %>
SessionID ${pageContext.session.id}
<%
// Initialize list on first load or when no parameters
are passed
if (session.getAttribute("list") == null ||
request.getParameter("listSize") == null) {
out.println("List is null,
creating");
session.setAttribute("list", new ArrayList());
}
out.println("Collection Size");
((List)session.getAttribute("list")).add(new
String("foo"));
%>
List size in session
Previous list size + 1:
Restart
---
end index.jsp
Thank you
Ivan
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:39 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
> 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming
RE: Session problems with cluster
Filip, here is a concrete case that you may find interesting. It's a
very simple JSP that stores a List in the session, adds an item to it on
every submission and then checks to see if there have been lost items
since the previous request.
To reproduce the error, just deploy in a cluster it and visit the page
(index.jsp) Our tests are consistent in that, the moment any other
clustered application is visited, this page will notify that it has lost
items.
Our main intention is to help identify the problem, because we believe!
Tomcat 5.0.25 (5.0.28 has the reload problem, so we downgraded)
JDK 1.4.2
Cluster config:
index.jsp
---
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"; %>
<%@ page import="java.util.*" %>
<%@ page import="java.net.*" %>
function submit_frm() {
if (document.testform.listSize.value !=
document.testform.listPrevSize.value)
alert('List out of sync: Reported size = ' +
document.testform.listSize.value + ', expected = ' +
document.testform.listPrevSize.value);
else
document.testform.submit();
}
self.setTimeout('submit_frm()', 200);
<%
out.println(java.net.InetAddress.getLocalHost().getHostName()); %>
SessionID ${pageContext.session.id}
<%
// Initialize list on first load or when no parameters
are passed
if (session.getAttribute("list") == null ||
request.getParameter("listSize") == null) {
out.println("List is null,
creating");
session.setAttribute("list", new ArrayList());
}
out.println("Collection Size");
((List)session.getAttribute("list")).add(new
String("foo"));
%>
List size in session
Previous list size + 1:
Restart
-------
end index.jsp
Thank you
Ivan
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:39 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
> 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session problems with cluster
> 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 en
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
> > >
> > > <%
> > > Object obj = request.getSession ().getAttribute ("my_object");
> > >
> > > if (obj == null) {
> > > out.println("MyObject was null. Adding instance to session, please
> > > start and stop context.");
> > > request.getSession ().setAttribute ("my_object", new
> > testpkg.MyObject
> > > ());
> > > } else {
> > > out.println ("MyObject was in session");
> > > out.println ("Do class names match: " + (obj.getClass
> > ().getName
> > > ().equals (testpkg.MyObject.class.getName (;
> > > out.println ("Are objects assignable: " + (obj instanceof
> > > testpkg.MyObject) + "");
> > >
> > > try {
> > > testpkg.MyObject o = (testpkg.MyObject) request.getSession
> > > ().getAttribute ("my_object");
> > > } catch (ClassCastException e) {
> > > out.println ("" + e);
> > > }
> > > }
> > >
> > > %>
> > >
> > >
> > > :MyObject.java
> > > package testpkg;
> > >
> &
RE: Session problems with cluster
What's concerning?
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.
Let me know when you have a good test case, as all my tests are coming
through just fine
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
> >
> > <%
> > Object obj = request.getSession ().getAttribute ("my_object");
> >
> > if (obj == null) {
> > out.println("MyObject was null. Adding instance to session, please
> > start and stop context.");
> > request.getSession ().setAttribute ("my_object", new
> testpkg.MyObject
> > ());
> > } else {
> > out.println ("MyObject was in session");
> > out.println ("Do class names match: " + (obj.getClass
> ().getName
> > ().equals (testpkg.MyObject.class.getName (;
> > out.println ("Are objects assignable: " + (obj instanceof
> > testpkg.MyObject) + "");
> >
> > try {
> > testpkg.MyObject o = (testpkg.MyObject) request.getSession
> > ().getAttribute ("my_object");
> > } catch (ClassCastException e) {
> > out.println ("" + e);
> > }
> > }
> >
> > %>
> >
> >
> > :MyObject.java
> > package testpkg;
> >
> > public class MyObject implements java.io.Serializable {
> > public int i = 0;
> > }
> >
> > web.xml
> >
> >
> > > PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
> > "http://java.sun.com/dtd/web-app_2_3.dtd";>
> >
> >
> > Test
> >
> >
> >
> >
> >
> > - 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
> wo
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
> >
> > <%
> > Object obj = request.getSession ().getAttribute ("my_object");
> >
> > if (obj == null) {
> > out.println("MyObject was null. Adding instance to session, please
> > start and stop context.");
> > request.getSession ().setAttribute ("my_object", new
> testpkg.MyObject
> > ());
> > } else {
> > out.println ("MyObject was in session");
> > out.println ("Do class names match: " + (obj.getClass
> ().getName
> > ().equals (testpkg.MyObject.class.getName (;
> > out.println ("Are objects assignable: " + (obj instanceof
> > testpkg.MyObject) + "");
> >
> > try {
> > testpkg.MyObject o = (testpkg.MyObject) request.getSession
> > ().getAttribute ("my_object");
> > } catch (ClassCastException e) {
> > out.println ("" + e);
> > }
> > }
> >
> > %>
> >
> >
> > :MyObject.java
> > package testpkg;
> >
> > public class MyObject implements java.io.Serializable {
> > public int i = 0;
> > }
> >
> > web.xml
> >
> >
> > > PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
> > "http://java.sun.com/dtd/web-app_2_3.dtd";>
> >
> >
> > Test
> >
> >
> >
> >
> >
> > - 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 -
> > >
Re: Session problems with cluster
feel free to send it directly to me, fhanik at apache dot org
Filip
- Original Message -
From: "Brantley Hobbs" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
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:[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
>
> <%
> Object obj = request.getSession ().getAttribute ("my_object");
>
> if (obj == null) {
> out.println("MyObject was null. Adding instance to session, please
> start and stop context.");
> request.getSession ().setAttribute ("my_object", new
testpkg.MyObject
> ());
> } else {
> out.println ("MyObject was in session");
> out.println ("Do class names match: " + (obj.getClass
().getName
> ().equals (testpkg.MyObject.class.getName (;
> out.println ("Are objects assignable: " + (obj instanceof
> testpkg.MyObject) + "");
>
> try {
> testpkg.MyObject o = (testpkg.MyObject) request.getSession
> ().getAttribute ("my_object");
> } catch (ClassCastException e) {
> out.println ("" + e);
> }
> }
>
> %>
>
>
> :MyObject.java
> package testpkg;
>
> public class MyObject implements java.io.Serializable {
> public int i = 0;
> }
>
> web.xml
>
>
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>
>
> Test
>
>
>
>
>
> - 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
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:[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
>
> <%
> Object obj = request.getSession ().getAttribute ("my_object");
>
> if (obj == null) {
> out.println("MyObject was null. Adding instance to session, please
> start and stop context.");
> request.getSession ().setAttribute ("my_object", new
testpkg.MyObject
> ());
> } else {
> out.println ("MyObject was in session");
> out.println ("Do class names match: " + (obj.getClass
().getName
> ().equals (testpkg.MyObject.class.getName (;
> out.println ("Are objects assignable: " + (obj instanceof
> testpkg.MyObject) + "");
>
> try {
> testpkg.MyObject o = (testpkg.MyObject) request.getSession
> ().getAttribute ("my_object");
> } catch (ClassCastException e) {
> out.println ("" + e);
> }
> }
>
> %>
>
>
> :MyObject.java
> package testpkg;
>
> public class MyObject implements java.io.Serializable {
> public int i = 0;
> }
>
> web.xml
>
>
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>
>
> Test
>
>
>
>
>
> - 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 &
RE: Session problems with cluster
Yes i'm pretty sure this will be done by the session manager. You can disable this
behaviour though. Have a look at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: 18 October 2004 23:52
To: Tomcat Users List
Subject: Re: Session problems with cluster
Matt,
No other nodes are up, so there's nothing to serialize. I could imagine that the
session of the old context could be serialized to the new context in order to preserve
state, although I
hope this isn't done.
Thanks,
Matthew
"Dale, Matt" wrote:
> Surely when you restart the context all the sessions will get serialised then
> reloaded so I would expect this behaviour. You would have to set the cluster to dump
> sessions on a reload.
>
> -Original Message-
> From: Matthew Stone [mailto:[EMAIL PROTECTED]
> Sent: 18 October 2004 20:09
> To: [EMAIL PROTECTED]
> 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]
>
>
>Name: InterScan_Disclaimer.txt
>InterScan_Disclaimer.txtType: Plain Text (text/plain)
>Encoding: 7bit
>
>
> -
> 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]
Any opinions expressed in this E-mail may be those of the individual and not
necessarily the company. This E-mail and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not the
intended recipient or the person responsible for delivering to the intended recipient,
be advised that you have received this E-mail in error and that any use or copying is
strictly prohibited. If you have received this E-mail in error please notify the
beCogent postmaster at [EMAIL PROTECTED]
Unless expressly stated, opinions in this email are those of the individual sender and
not beCogent Ltd. You must take full responsibility for virus checking this email and
any attachments.
Please note that the content of this email or any of its attachments may contain data
that falls within the scope of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully compliant with the terms and
provisions of the Data Protection Act 1984 and 1998.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session problems with cluster
Matt,
No other nodes are up, so there's nothing to serialize. I could imagine that the
session of the old context could be serialized to the new context in order to preserve
state, although I
hope this isn't done.
Thanks,
Matthew
"Dale, Matt" wrote:
> Surely when you restart the context all the sessions will get serialised then
> reloaded so I would expect this behaviour. You would have to set the cluster to dump
> sessions on a reload.
>
> -Original Message-
> From: Matthew Stone [mailto:[EMAIL PROTECTED]
> Sent: 18 October 2004 20:09
> To: [EMAIL PROTECTED]
> 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]
>
>
>Name: InterScan_Disclaimer.txt
>InterScan_Disclaimer.txtType: Plain Text (text/plain)
>Encoding: 7bit
>
>
> -
> 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: Session problems with cluster
Surely when you restart the context all the sessions will get serialised then reloaded
so I would expect this behaviour. You would have to set the cluster to dump sessions
on a reload.
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: 18 October 2004 20:09
To: [EMAIL PROTECTED]
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]
Any opinions expressed in this E-mail may be those of the individual and not
necessarily the company. This E-mail and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not the
intended recipient or the person responsible for delivering to the intended recipient,
be advised that you have received this E-mail in error and that any use or copying is
strictly prohibited. If you have received this E-mail in error please notify the
beCogent postmaster at [EMAIL PROTECTED]
Unless expressly stated, opinions in this email are those of the individual sender and
not beCogent Ltd. You must take full responsibility for virus checking this email and
any attachments.
Please note that the content of this email or any of its attachments may contain data
that falls within the scope of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully compliant with the terms and
provisions of the Data Protection Act 1984 and 1998.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
<%
Object obj = request.getSession ().getAttribute ("my_object");
if (obj == null) {
out.println("MyObject was null. Adding instance to session, please start and stop
context.");
request.getSession ().setAttribute ("my_object", new testpkg.MyObject ());
} else {
out.println ("MyObject was in session");
out.println ("Do class names match: " + (obj.getClass ().getName ().equals
(testpkg.MyObject.class.getName (;
out.println ("Are objects assignable: " + (obj instanceof testpkg.MyObject) +
"");
try {
testpkg.MyObject o = (testpkg.MyObject) request.getSession
().getAttribute ("my_object");
} catch (ClassCastException e) {
out.println ("" + e);
}
}
%>
:MyObject.java
package testpkg;
public class MyObject implements java.io.Serializable {
public int i = 0;
}
web.xml
http://java.sun.com/dtd/web-app_2_3.dtd";>
Test
- 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]
Re: Session problems with cluster
>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]
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]
