Indeed, looking at the changelogs we see that clustering was not changed in those versions. That and the error messages lead me to think that it has to do with the "context manager" not surviving reloads, not clustering in itself. IMHO anyway...
Thanks Filip. Ivan. -----Original Message----- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 12:11 PM To: Tomcat Users List Subject: Re: Clustering and session replication oh, really, not a problem in 5.0.25, very interesting, please add that to the comments as the actual cluster code didn't change between those versions if my memory serves me right Filip ----- Original Message ----- From: "Ivan Vasquez" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Thursday, September 30, 2004 10:49 AM Subject: RE: Clustering and session replication Filip, We will file a bug. In the meantime we will try 5.0.25 as it appears it doesn't have the problem. Thanks a lot. Ivan. -----Original Message----- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 11:39 AM To: Tomcat Users List Subject: Re: Clustering and session replication ok, so when the context is reloaded you are saying it doesn't work. sounds like that upon a context reload the new context does not get a ClusterManager, and instead gets the StandardManager assigned. File a bug in bugzilla, and we will take care of it We never reload our contexts in production so that is why I haven't seen what you are seeing Filip ----- Original Message ----- From: "Ivan Vasquez" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Cc: "Brian Lawrence" <[EMAIL PROTECTED]> Sent: Thursday, September 30, 2004 10:05 AM Subject: RE: Clustering and session replication Filip, To discard any problems in application settings, we copied an entire application from production (clustered tomcat 5.0.25) to the cluster that's having problems (5.0.28). We verified context settings and load balancing. The first time the application is used after a tomcat restart, it works well (load balancing and session replication). But after reloading the application in any node (i.e. context reloads), the log will show the warnings and timeout errors that I described before. Session replication fails from that point on. >From the little I understand, I think clustering is doing its job, the problem is it cannot find the "context manager" for that application (despite both nodes have <distributable/> in web.xml). However, the context is properly configured because we can access dbcp pools and mail connections defined within. Ivan. -----Original Message----- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 5:14 PM To: Tomcat Users List Subject: Re: Clustering and session replication let me reiterate org.apache.catalina.cluster.tcp.SimpleTcpCluster messageDataReceived WARNING: Context manager doesn't exist:/nahrgisdev that means there is no clustered context under this name. If it works from server 1 to 2 but not from 2 to 1, then you need to look over your configuration again. The good news is it worked for you in one direction, you have to focus on the above error message, that message and that message alone is the reason the requesting server times out Filip ----- Original Message ----- From: "Ivan Vasquez" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Wednesday, September 29, 2004 3:54 PM Subject: RE: Clustering and session replication Filip, Thanks for your reply. Each app has identical web.xml files: <?xml version="1.0" encoding="ISO-8859-1"?> <!-- Required in order to have default EL support --> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd" version="2.4"> <distributable/> <!-- General description of your web application --> <display-name>NAHRGIS Clustered</display-name> <description> NAHRGIS GIS Application </description> ... The context, with datasources and other resources, works as expected (but it lives in conf/Catalina/localhost/nahrgisdev.xml, not in server.xml). The cluster is set as follows: <Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" managerClassName="org.apache.catalina.cluster.session.DeltaManager" expireSessionsOnShutdown="false" useDirtyFlag="false"> <Membership className="org.apache.catalina.cluster.mcast.McastService" mcastAddr="228.0.0.4" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000"/> <Receiver className="org.apache.catalina.cluster.tcp.ReplicationListener" tcpListenAddress="10.0.0.1" tcpListenPort="4001" tcpSelectorTimeout="100" tcpThreadCount="6"/> <Sender className="org.apache.catalina.cluster.tcp.ReplicationTransmitter" replicationMode="pooled"/> <Valve className="org.apache.catalina.cluster.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"/> <Deployer className="org.apache.catalina.cluster.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/" watchDir="/tmp/war-listen/" watchEnabled="false"/> </Cluster> After further testing, one node consistently times out upon reload: requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://10.0.0.2:4001,10.0.0 .2,4001 ... SEVERE: Manager[/nahrgisdev], No session state received, timing out While the other one gets it in 100 or so ms. Respectfully, Ivan. -----Original Message----- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 4:17 PM To: Tomcat Users List Subject: Re: Clustering and session replication org.apache.catalina.cluster.tcp.SimpleTcpCluster messageDataReceived WARNING: Context manager doesn't exist:/nahrgisdev this is telling you that the server that spits out this message does not have a <distributable/> context configured by the name "nahrgisdev" all the servers in the cluster must have the all the "<distributable/>" webapps configured identically Filip ----- Original Message ----- From: "Ivan Vasquez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 29, 2004 3:03 PM Subject: Clustering and session replication We are having some problems with a cluster of 2x Tomcat 5.0.28 (JDK 1.4.2) regarding session replication. The problem manifests after a distributable application is reloaded. From that point on, a successful login to our application causes the same page to be reloaded by the other node (mod_jk is load balancing) as if no progress was being done. A new session ID is generated every time by either node. Every time it happens, the log shows: org.apache.catalina.cluster.tcp.SimpleTcpCluster messageDataReceived WARNING: Context manager doesn't exist:/nahrgisdev On application reload, a node shows this error Sep 29, 2004 3:47:26 PM org.apache.catalina.cluster.session.DeltaManager start WARNING: Manager[/nahrgisdev], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://128.192.104.11:4001, 128.192.104.11,4001, alive=253140]. This operation will timeout if no session state has been received within 60 seconds Sep 29, 2004 3:48:26 PM org.apache.catalina.cluster.session.DeltaManager start SEVERE: Manager[/nahrgisdev], No session state received, timing out. However, we can telnet the other side on that port. Internal NICs are not configured for the cluster because initially we thought they were the problem. The application's context is stored in conf/Catalina/localhost/nahrgisdev.xml. Of course, the application works well in a non-clustered environment. Thanks for any advice, Ivan. --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
