[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ https://issues.apache.org/jira/browse/GERONIMO-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463857 ] Kaoru Matsumura commented on GERONIMO-2577: --- Hello Jeff and Shiva, I'm sorry to be late for reply. I tried your new-config.xml and geronimo-web-hostlevel.xml(Host level Clustering)on my RHEL environment. Good! The clustering works perfectly. The same as your case , session gets preserved successfully even onto the 3rd remaining node. Would you please tell me why clustering doesn't work successfully (Context level Clustering + DeltaManager) ? Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: https://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Clustering, Tomcat >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: config.xml, context.xml, geronimo-new.log, > geronimo-web-hostlevel.xml, geronimo-web-new.xml, geronimo-web-nodeB.xml, > geronimo-web-nodeC.xml, geronimo-web.xml, new-config.xml, server-nodeA.xml, > server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMembe
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12461384 ] Kaoru Matsumura commented on GERONIMO-2577: --- OK . I'll try it. Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: config.xml, context.xml, geronimo-new.log, > geronimo-web-new.xml, geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: geronimo-new.log Adding information I have attached the whole geronimo.log(except [McastService] ping) of the last remaining node. in using your geronimo-web-new.xml. 15:20:40 first node was down. 15:22:50 second node was down. 15:23:07 new sessionid was created. > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: context.xml, geronimo-new.log, geronimo-web-new.xml, > geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, geronimo-web.xml, > server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDa
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12461148 ] Kaoru Matsumura commented on GERONIMO-2577: --- Thank you for advice. I tried your geronimo-web-new.xml. I observed the same log message as you noticed. But the results of the test were the same. > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: context.xml, geronimo-web-new.xml, > geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, geronimo-web.xml, > server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12460741 ] Kaoru Matsumura commented on GERONIMO-2577: --- Jeff, I found the following log messages regarding to NextListener in the start of geronimo cluster. The message "no targets are running for reference NextListener matching " is right ? nodeA - 2006-12-25-11-10-29-691 DEBUG [GBeanSingleReference] Waiting to start geronimo/ClusterCheck/1.1/war?J2EEApplication=null,WebModule=geronimo/ClusterCheck/1.1/war,j2eeType=MessageListener,name=ClusterSessionListener because no targets are running for reference NextListener matching the patterns geronimo/ClusterCheck/1.1/war?J2EEApplication=null,WebModule=geronimo/ClusterCheck/1.1/war,j2eeType=MessageListener,name=JvmRouteSessionIDBinderListener - The same messages as nodeB or nodeC. "ClusterCheck" is our test Application. > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: context.xml, geronimo-web-nodeB.xml, > geronimo-web-nodeC.xml, geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, > server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12460737 ] Kaoru Matsumura commented on GERONIMO-2577: --- Thanks, Jeff As I see, in our environment, "NextListener" is being used, not "nextListener". Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: context.xml, geronimo-web-nodeB.xml, > geronimo-web-nodeC.xml, geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, > server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.1
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: context.xml Here is the Tomcat5.5.15 context.xml using every node > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: context.xml, geronimo-web-nodeB.xml, > geronimo-web-nodeC.xml, geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, > server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: server-nodeC.xml Here is the Tomcat5.5.15 server-.xml using nodeC > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [Da
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: server-nodeB.xml Here is the Tomcat5.5.15 server-.xml using nodeB > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [Da
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: server-nodeA.xml Here is the Tomcat5.5.15 server-.xml using nodeA > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12460729 ] Kaoru Matsumura commented on GERONIMO-2577: --- Thank you for reply. I added the following line to my geronimo-web.xml's 31st line. ClusterSessionListener also added the following to 93rd line. JvmRouteSessionIDBinderListener But the results were the same. So I post my Tomcat5.5.15 configuration files (server.xml and context.xml). context.xml is not editted anything from default in each node. Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > g
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: geronimo-web-nodeC.xml Here is the geronimo-web.xml using nodeC > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [DataSender] Sender close socket to [192.168.1.1:4,001] >
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: geronimo-web-nodeB.xml Here is the geronimo-web.xml using nodeB > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, > geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [DataSender] Sender close socket to [192.168.1.1:4,001] >
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12460242 ] Kaoru Matsumura commented on GERONIMO-2577: --- Thank you for reply. 1) No. This problem doesn't depend on nodes. 2) Yes. 3) Yes. 4) This means that when we changed DeltaManager to SimpleTcpReplicationManager, the process can continue at the nodeC(the last node). So we avoid this problem using SimpleTcpReplicationManager. 21th lines of the geronimo-web.xml --- managerClassName=org.apache.catalina.cluster.session.DeltaManager ↓ managerClassName=org.apache.catalina.cluster.session. SimpleTcpReplicationManager --- In the case of Tomcat, This problem doesn't happen , even if using DeltaManager. 5) Yes. 6) Yes. 7) Yes. 8) OK. 9) Whether useDirtyFlag is true or false, the results were the same. So we set useDirtyFlag to true. 10) When mcastBindAddress is set on Linux, it seems that multicast packet can not be accepted. So I removed mcastBindAddress from all of the nodes. This matter is the same as Tomcat and Geronimo. 11) No,I haven't. So I tried it. But the results were the same. There is an interest for me, At the point of (*1), nodeC's log in Description this probrem report shows, 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=130441]] 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. However, at the point of (*3), nodeC's log shows, 20:06:40,652 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.2:4001,catalina,192.168.1.2,4001, alive=113760]] These are different. the case of 2nd, the line of 'received session' was not printed in the log after this time. I think this is related. thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DE
[jira] Updated: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=all ] Kaoru Matsumura updated GERONIMO-2577: -- Attachment: geronimo-web.xml Here is the geronimo-web.xml using this test. > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Clustering, Tomcat >Affects Versions: 1.1.1, 1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [MapperListener] Handle > geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : > JMX.mbean.unregistered > 20:06:39,818 DEBUG [DataSender] Sender close socket to [192.168.1.1:4,001] > (close count 1) > 20:06:39,818 DEBUG [DataSender]
[jira] Created: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down. Key: GERONIMO-2577 URL: http://issues.apache.org/jira/browse/GERONIMO-2577 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering, Tomcat Affects Versions: 1.1.1, 1.1 Environment: JDK - Sun java version "1_5_0_09"(32bit) OS- Red Hat Enterprise Linux ES4 update4(32bit) Http Server - Apache 2.0.59 +mod_jk 1.2.19 Reporter: Kaoru Matsumura We run Geronimo cluster with three nodes. In our environment, with DeltaManager set for replication module, we found that the last node cound not continue the processes when the other nodes is intentionally halted in order. We recognize Tomcat 5.5.15 is OK with the same configuration and operations. Test Application The Web application program, which was used for the test, simply reads the number of access count, and then write the count to HttpSession object. Configuration Files == We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html * config.xml We add the following parameters to the standard configuration. name=Geronimo jvmRoute=nodeA Operations === 1 Have browser access to Test Application , and reload several times.(*1) HttpSession object is created on the nodeA. 2 And then, We kill the process of geronimo on the nodeA with $kill -9 .(*2) 3 Reload the browser at one time. The node changes to nodeB.(*3) 4 Reload the browser several times.(*4) 5 And then, We kill the process of geronimo on the nodeB with $kill -9 .(*5) 6 Reload the browser at one time.(And then, We expect that the process continues at the nodeC.) But the HttpSessionID of the HttpSession object is changed to another ID and the counter value is back to 1.(*6) As a result, the geronimo cluster cannot continue the process. For avoidance === When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process. Debug levels logs == (*1) nodeA -- 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is 7160C8614D20687D3548E8488AB65AC3.nodeA 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL PROTECTED] at /ClusterCheck 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec 20:06:17,737 DEBUG [MsgContext] COMMIT 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === 20:06:17,737 DEBUG [MsgContext] CLOSE 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on /ClusterCheck/counter 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. 20:06:17,757 DEBUG [McastService] Mcast receive ping from member org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, alive=58960] --- nodeC --- 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 ms. 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=130441]] 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. --- (*2) nodeB (same as nodeC) --- 20:06:39,817 INFO [SimpleTcpCluster] Received member disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=149288] 20:06:39,818 DEBUG [MapperListener] Handle geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : JMX.mbean.unregistered 20:06:39,818 DEBUG [MapperListener] Handle geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : JMX.mbean.unregistered 20:06:39,818 DEBUG [MapperListener] Handle geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : JMX.mbean.unregistered 20:06:39,818 DEBUG [DataSender] Sender close socket to [192.168.1.1:4,001] (close count 1) 20:06:39,818 DEBUG [DataSender] Sender disconnect from [192.168.1.1:4,001] (disconnect count 1) -- (*3) nodeB --- 20:06:40,640 DEBUG [CoyoteAdapter] Requested cookie session id is 7160C8614D20687D3548E8488AB65AC3.nodeA 20:06:40,641 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL PROTECTED] at /ClusterCheck 20:06:40,641 DEBUG [JvmRouteBinderValve] Detected a failover with different jvmRoute - orginal route: [nodeA] new one: [nodeB] at session id [7
