You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christian Schuhegger <Ch...@gmx.de> on 2005/07/10 08:19:25 UTC
session replication problem: ClassCastException
hello,
we have since two weeks a problem with session replication.
we use jakarta-tomcat-5.5.4.tar.gz with the compatibility package for
jdk1.4 on a redhat advanced server.
we are sure that session replication was still working roughly two weeks
ago, but the only thing we remember that we changed during that time was
the layout of the configuration files, e.g. instead of having the
server.xml file directly in the conf directory we created a link to this
file which resides now in another directory. we did this for several
parts of our tomcat configuration. otherwise we are quite sure we did
not change anything else.
we did not change our web application during that time and in addition
we have taken extensive measures to make sure that all objects that are
put into the session are serializable.
the problem we have looks like this on the tomcat which tries to
serialize the session:
-- snip start --
SCHWERWIEGEND: Failed to serialize the session!
java.lang.ClassCastException
at
org.apache.catalina.cluster.session.SimpleTcpReplicationManager.writeSession(SimpleTcpReplicationManager.java:326)
at
org.apache.catalina.cluster.session.SimpleTcpReplicationManager.requestCompleted(SimpleTcpReplicationManager.java:292)
at
org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:188)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
-- snip end --
and like this on the other end:
-- snip start --
SCHWERWIEGEND: Failed to deserialize the session!
java.lang.NullPointerException
at
java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:89)
at
org.apache.catalina.cluster.session.SimpleTcpReplicationManager.readSession(SimpleTcpReplicationManager.java:352)
at
org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageReceived(SimpleTcpReplicationManager.java:551)
at
org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageDataReceived(SimpleTcpReplicationManager.java:590)
at
org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(SimpleTcpCluster.java:548)
at
org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:69)
at
org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpReplicationThread.java:126)
at
org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationThread.java:64)
-- snip end --
the one thing which is VERY strange to me is that normally with a
ClassCastException you get the type info of which class it tries to
cast, but here we only get "java.lang.ClassCastException"?
we tried to search google for people having similar problems, but we
were not able to find any references to such a problem. perhaps somebody
on this list is able to help us with this issue?
--
Christian Schuhegger
http://www.el-chef.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session replication problem: ClassCastException
Posted by Christian Schuhegger <Ch...@gmx.de>.
Hi Peter,
thank you very much for your quick response! I have more information on
this topic now.
Peter Rossbach wrote:
> First your are sure that your wars inside the installation art identical?
Yes I am. Our automated install procedure ensures that.
> You stacktraces are strange.
> The cast inside writeSession use only tomcat classes!
> Have you change the authorisation and use your own principal
> implementation ?
No. We did no such changes. I already thought it might have something to
do with different Classloaders used by the two tomcats, but I know too
little about the Classloaders that tomcat uses to judge this suspicion.
> For more help I think do the following steps
> a) update to tomcat 5.5.9
> b) install the cluster fix ( The Bug Database
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34389)
> c) change your Cluster Config from SimpleTcpReplicationManager to
> DeltaManager
> d) Use fastasyncqueue mode.
We die the same modifications to our testcluster now. Because the
configuration files are autogenerated i am sure that the config files
are the same except the details that have to be different (like machine
names etc.). Besides that we have exactly the same software (webapp)
running on the testcluster.
The interesting part is that we do not see these ClassCastExceptions in
the testcluster?
I originally thought that it might be that we got something wrong with
the tomcat set-up and i've reinstalled tomcat 5.5.4 plus jdk1.4 patch on
the production machines but this did not help.
We also noticed that these class cast exceptions do not depend on the
numbers of sessions we have. They are roughly constant at roughly 2 such
exceptions per minute, even during the night where our session count
drops to basically 0.
We currently cannot upgrade to tomcat 5.5.9 because of our upgrade
policy to only upgrade software when it was extensively tested in our
test environment.
Via Google I only found one post with a remotely similar problem:
http://www.junlu.com/msg/65888.html
otherwise I have no more Ideas on how to continue from here.
Do you see any other way how to analyse and debug this problem?
Thank you very much!
--
Christian Schuhegger
http://www.el-chef.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session replication problem: ClassCastException
Posted by Peter Rossbach <pr...@objektpark.de>.
Hmm,
First your are sure that your wars inside the installation art identical?
You stacktraces are strange.
The cast inside writeSession use only tomcat classes!
Have you change the authorisation and use your own principal
implementation ?
For more help I think do the following steps
a) update to tomcat 5.5.9
b) install the cluster fix ( The Bug Database
http://issues.apache.org/bugzilla/show_bug.cgi?id=34389)
c) change your Cluster Config from SimpleTcpReplicationManager to
DeltaManager
d) Use fastasyncqueue mode.
Peter
Christian Schuhegger schrieb:
> hello,
>
> we have since two weeks a problem with session replication.
>
> we use jakarta-tomcat-5.5.4.tar.gz with the compatibility package for
> jdk1.4 on a redhat advanced server.
>
> we are sure that session replication was still working roughly two
> weeks ago, but the only thing we remember that we changed during that
> time was the layout of the configuration files, e.g. instead of having
> the server.xml file directly in the conf directory we created a link
> to this file which resides now in another directory. we did this for
> several parts of our tomcat configuration. otherwise we are quite sure
> we did not change anything else.
>
> we did not change our web application during that time and in addition
> we have taken extensive measures to make sure that all objects that
> are put into the session are serializable.
>
> the problem we have looks like this on the tomcat which tries to
> serialize the session:
>
> -- snip start --
> SCHWERWIEGEND: Failed to serialize the session!
> java.lang.ClassCastException
> at
> org.apache.catalina.cluster.session.SimpleTcpReplicationManager.writeSession(SimpleTcpReplicationManager.java:326)
>
> at
> org.apache.catalina.cluster.session.SimpleTcpReplicationManager.requestCompleted(SimpleTcpReplicationManager.java:292)
>
> at
> org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:188)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>
> at java.lang.Thread.run(Thread.java:534)
> -- snip end --
>
> and like this on the other end:
> -- snip start --
> SCHWERWIEGEND: Failed to deserialize the session!
> java.lang.NullPointerException
> at
> java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:89)
> at
> org.apache.catalina.cluster.session.SimpleTcpReplicationManager.readSession(SimpleTcpReplicationManager.java:352)
>
> at
> org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageReceived(SimpleTcpReplicationManager.java:551)
>
> at
> org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageDataReceived(SimpleTcpReplicationManager.java:590)
>
> at
> org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(SimpleTcpCluster.java:548)
>
> at
> org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:69)
> at
> org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpReplicationThread.java:126)
>
> at
> org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationThread.java:64)
>
> -- snip end --
>
> the one thing which is VERY strange to me is that normally with a
> ClassCastException you get the type info of which class it tries to
> cast, but here we only get "java.lang.ClassCastException"?
>
> we tried to search google for people having similar problems, but we
> were not able to find any references to such a problem. perhaps
> somebody on this list is able to help us with this issue?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org