Re: session replication problem: ClassCastException
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
Mladen Turk wrote: Take a look at: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html It clearly states that (big warning in red color) The name of the worker can contain only the alphanumeric characters [a-z][A-Z][0-9] and is case insensitive. So tc1.tc1 is illegal name for the worker. thanks for that hint, but actually luckily this is working. the real problem is that the value that i specify for the jvmRoute is magically doubled and i only doubled this name in the workers.properties file as a short term workaround. i still did not find out why this jvmRoute parameter is doubled in my applications, but not in the servlets-examples/servlet/SessionExample application. -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
hello, i've just tried to set-up tomcat 5.5 with apache2 and mod_jk version 1.2.8 in a load balancing set-up with sticky sessions. when i give as jvmRoute parameter the string tc1 my sessionids look like: BF20EF21CC52EA0659B1E079015D7B56.tc1.tc1 and i see in the mod_jk.log file that no worker with the name tc1.tc1 could be found! i've circumvented the problem currently by doubling the name in the workers.properties file as follows: -- snip start -- worker.list=load worker.load.type=lb worker.load.balance_workers=tc1.tc1,tc2.tc2 worker.load.sticky_session=True worker.tc1.tc1.port=12013 worker.tc1.tc1.host=localhost worker.tc1.tc1.type=ajp13 worker.tc2.tc2.port=12013 worker.tc2.tc2.host=remote worker.tc2.tc2.type=ajp13 -- snip end -- was this problem already noticed? did i do something wrong? or should i file a bug report? thanks, -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in tomcat 5.5 and sticky sessions because of problem with jvmRoute parameter?
Remy Maucherat wrote: - Added jvmRoute=tc1 on Engine - Accessed http://127.0.0.1:8080/servlets-examples/servlet/SessionExample - Session ID displayed is 8DBBCECBCAD078E18C07401A076734B0.tc1 i've just tried this example myself and you're right. i see only .tc1. i have a very little webapp which does similar things to test the distributed set-up and a our main big application and both have the same problem with this double tc1.tc1. i will try to find out why i have it in the one case but not in the other? nevertheless i anybody experienced similar problems and found out where the problem comes from i would be very happy to hear about it. thanks, -- Christian Schuhegger http://www.el-chef.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
