Re: Tomcat classloading...a theory question..
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html Ben Bookey wrote: Dear List, Which packages would normally be used by an app. running on Tomcat 4 and Tomcat 5, if identical packages are placed in the paths, i) common\lib ii) mywebapp\WEB-INF\lib iii) jre\lib\ext (Java-Run-Time) It would be logical to me that the version in the app WEB-INF\lib directory would be used 'first' before the TC ClassLoader looks into the common lib. I have been responsible for the dev of an wepapp. which often runs alongside other apps. To avoid the bugs that the customers often have, I would like to put ALL the trouble jar files (in my case the xml parser api jar files), inside my webapp and these will be hopefully used by my app. rather than it using possibly older versions that have been placed inside of the common/lib or even the jre\lib path. I would really appreciate any insight. regards Ben Bookey - 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
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 (liMyObject was in session);
out.println (liDo class names match: + (obj.getClass
().getName
().equals (testpkg.MyObject.class.getName (;
out.println (liAre 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-nameTest/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
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 (liMyObject was in session);
out.println (liDo class names match: + (obj.getClass
().getName
().equals (testpkg.MyObject.class.getName (;
out.println (liAre 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-nameTest/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
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, 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 (liMyObject was in session);
out.println (liDo class names match: + (obj.getClass
().getName
().equals
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]
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 (liMyObject was in session);
out.println (liDo class names match: + (obj.getClass ().getName ().equals
(testpkg.MyObject.class.getName (;
out.println (liAre 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-nameTest/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]
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]
Server-wide TR.properties
Greetings. Someone in the turbine-users list suggested I post this message here: Could someone please explain to me the correct way to configure Tomcat to use several Turbine web-app's that are shared between each other. For example, I have web-app's A, B C. A - contains velocity stuff and a Turbine service I created B - contains another Turbine service I created C - contains legacy jsp pages and acts as front end to A B I know it looks like I've answer my own questions below but please read it all the way through if you are looking to help me because I think my answers will help shed light on my confusion. Here are my specific questions: 1. Where should the Turbine related JAR's be stored in the Tomcat directory structure? In \tomcat\lib or each respective \webapp\web-inf\lib directory? I believe it should be the former for 2 reasons. First it's cleaner than having the JAR's duplicated. Second and most important because the runtime will create multiple instances of the TurbineServices singleton thus not allowing web-app C to locate the services in A B. 2. Should the services I've created in web-app's A B be moved out of the web-app into a shared location in the Tomcat directory? Again I believe the answer is yes because web-app C needs to be able to resolve the class names for the services in A B. 3. Finally the question I don't have the answer for. If my answers are correct for questions 1 2, how do I configure Tomcat to only use 1 TurbineResources.properties file. For example, could I drop it into the tomcat\conf directory and have it init all my services from there? If so, what XML file do I change and what should I put in it? Right now web-app's A B each have their own unique TR.Prop files in their respective \web-inf\conf directories and all of the settings are the same. Then at the end of the TR.prop file I use include=A.properties to specify specific variables for service A and I also do the same thing for web-app B changing the include=B.properties accordingly. The bottom line is there a more elegant way to do this? Please let me know if you need more information. Thanks in advance! Regards, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
