我在同一台服务器上运行了两个apache-tomcat-7.0.41实例，我观察到的奇怪行为是在同一浏览器上多个登录/注销的服务器之间共享会话，但是当我切换浏览器，会话共享停止。
我尝试通过打印创建的＆amp; amp;来找到Find number of active sessions created from a given client IP中提到的活动会话。被摧毁的会议
@Override
public void sessionDestroyed(HttpSessionEvent event) {
System.out.println("Session Destroyed::: "+event.getSession().getId());
}
@Override
public void sessionCreated(HttpSessionEvent event) {
System.out.println("New Session ::: "+event.getSession().getId());
}
使用chrome时由此产生的日志： 我登录的tomcat：
Session Destroyed::: AC526EC82AF5E6F6F46A0BD9441EAAF0.SERVER-1
New Session ::: F87CCF46CC3318A758F3700D6437DDC4.SERVER-1
New Session ::: D0B6D84056544E7C0F425191010B1D08.SERVER-1
Session Destroyed::: F87CCF46CC3318A758F3700D6437DDC4.SERVER-1
New Session ::: 87EBFFA05489A2B22A1CD13352DC8688.SERVER-1
Session Destroyed::: 87EBFFA05489A2B22A1CD13352DC8688.SERVER-1
New Session ::: A00EC8504F9B4A93A6CD511B4EA64D0B.SERVER-1
New Session ::: 542841168FB92E17B2946EE5D194A439.SERVER-1
New Session ::: 6CAE12739B17D7C86E5596EBB3B364FD.SERVER-1
New Session ::: FE483E49AFA99D939E5C534C4E6428BF.SERVER-1
New Session ::: 3B6B21B01320EDD1A56C9A54DFAEDAB6.SERVER-1
Session Destroyed::: A00EC8504F9B4A93A6CD511B4EA64D0B.SERVER-1
New Session ::: 39BAD300FBEC2A55C770BEA3A0A78BA3.SERVER-1
另一个tomcat：
New Session ::: F87CCF46CC3318A758F3700D6437DDC4.SERVER-1
New Session ::: D0B6D84056544E7C0F425191010B1D08.SERVER-1
Session Destroyed::: F87CCF46CC3318A758F3700D6437DDC4.SERVER-1
New Session ::: 87EBFFA05489A2B22A1CD13352DC8688.SERVER-1
Session Destroyed::: 87EBFFA05489A2B22A1CD13352DC8688.SERVER-1
New Session ::: A00EC8504F9B4A93A6CD511B4EA64D0B.SERVER-1
New Session ::: 542841168FB92E17B2946EE5D194A439.SERVER-1
New Session ::: 6CAE12739B17D7C86E5596EBB3B364FD.SERVER-1
New Session ::: FE483E49AFA99D939E5C534C4E6428BF.SERVER-1
New Session ::: 3B6B21B01320EDD1A56C9A54DFAEDAB6.SERVER-1
Session Destroyed::: A00EC8504F9B4A93A6CD511B4EA64D0B.SERVER-1
New Session ::: 39BAD300FBEC2A55C770BEA3A0A78BA3.SERVER-1
当我切换到Firefox时： 我登录的tomcat：
New Session ::: BE144AA97F9006D584D10D8FB5BB84B4.SERVER-1
Session Destroyed::: BE144AA97F9006D584D10D8FB5BB84B4.SERVER-1
New Session ::: FF0C14863E36DD748911B0209A089A87.SERVER-1
Session Destroyed::: FF0C14863E36DD748911B0209A089A87.SERVER-1
New Session ::: 6003A09956987A2035EB9BB1C5D7C157.SERVER-1
New Session ::: 2F3D59D9CD286F52C2B0C25FFEB646B5.SERVER-1
Session Destroyed::: 6003A09956987A2035EB9BB1C5D7C157.SERVER-1
New Session ::: F6DAA85FE306B0BBAAB9165216AA7290.SERVER-1
New Session ::: 2A5CBDDFB3B2A3CFBD39DDDF4679387F.SERVER-1
Session Destroyed::: F6DAA85FE306B0BBAAB9165216AA7290.SERVER-1
New Session ::: FA44460CD84449E303CF8D460DB016D4.SERVER-1
Session Destroyed::: FA44460CD84449E303CF8D460DB016D4.SERVER-1
New Session ::: 7DCF3832ABF83590543667DC4614151C.SERVER-1
New Session ::: 1066B025A7FBB295C6BD1043B9724322.SERVER-1
New Session ::: 62133E533528AD516061B09E65AFD175.SERVER-1
Session Destroyed::: 7DCF3832ABF83590543667DC4614151C.SERVER-1
New Session ::: C1FB38B4F6F0BA9AB1C43E5BD63B2ADC.SERVER-1
New Session ::: A3DFDFF36B39FE46C3074893AD312966.SERVER-1
Session Destroyed::: 62133E533528AD516061B09E65AFD175.SERVER-1
New Session ::: 16753CA90D112DE434ABA8A71F567C15.SERVER-1
Session Destroyed::: A3DFDFF36B39FE46C3074893AD312966.SERVER-1
New Session ::: F616A40375D798AB04D25B37F8FEFCF3.SERVER-1
Session Destroyed::: C1FB38B4F6F0BA9AB1C43E5BD63B2ADC.SERVER-1
New Session ::: A425ED49A28347E305B5EE0CC22A03ED.SERVER-1
Session Destroyed::: A425ED49A28347E305B5EE0CC22A03ED.SERVER-1
New Session ::: B3D9E3632685A6DEB53F753AE53145F1.SERVER-1
Session Destroyed::: D0B6D84056544E7C0F425191010B1D08.SERVER-1
Session Destroyed::: 39BAD300FBEC2A55C770BEA3A0A78BA3.SERVER-1
Session Destroyed::: 542841168FB92E17B2946EE5D194A439.SERVER-1
Session Destroyed::: 3B6B21B01320EDD1A56C9A54DFAEDAB6.SERVER-1
Session Destroyed::: 6CAE12739B17D7C86E5596EBB3B364FD.SERVER-1
Session Destroyed::: FE483E49AFA99D939E5C534C4E6428BF.SERVER-1
Session Destroyed::: 2F3D59D9CD286F52C2B0C25FFEB646B5.SERVER-1
Session Destroyed::: 2A5CBDDFB3B2A3CFBD39DDDF4679387F.SERVER-1
Session Destroyed::: 16753CA90D112DE434ABA8A71F567C15.SERVER-1
Session Destroyed::: F616A40375D798AB04D25B37F8FEFCF3.SERVER-1
Session Destroyed::: 1066B025A7FBB295C6BD1043B9724322.SERVER-1
Session Destroyed::: B3D9E3632685A6DEB53F753AE53145F1.SERVER-1
Session Destroyed::: 2F43D41620B158302343EB309D94E929.SERVER-1
另一个tomcat：
New Session ::: BE144AA97F9006D584D10D8FB5BB84B4.SERVER-1
New Session ::: 1066B025A7FBB295C6BD1043B9724322.SERVER-1
New Session ::: 62133E533528AD516061B09E65AFD175.SERVER-1
Session Destroyed::: D0B6D84056544E7C0F425191010B1D08.SERVER-1
Session Destroyed::: 542841168FB92E17B2946EE5D194A439.SERVER-1
Session Destroyed::: 3B6B21B01320EDD1A56C9A54DFAEDAB6.SERVER-1
Session Destroyed::: 6CAE12739B17D7C86E5596EBB3B364FD.SERVER-1
Session Destroyed::: FE483E49AFA99D939E5C534C4E6428BF.SERVER-1
Session Destroyed::: 62133E533528AD516061B09E65AFD175.SERVER-1
Session Destroyed::: 1066B025A7FBB295C6BD1043B9724322.SERVER-1
Session Destroyed::: 39BAD300FBEC2A55C770BEA3A0A78BA3.SERVER-1
Session Destroyed::: BE144AA97F9006D584D10D8FB5BB84B4.SERVER-1
从日志中可以看出会话信息由于从chrome切换到firefox的某些原因没有传送到第二台服务器，这看起来很奇怪，但我可以复制firefox＆amp;的行为。野生动物园。
我尝试了Tomcat's Clustering / Session Replication not replicating properly
中提到的解决方案虽然它不起作用，但第二个答案提到使用channelSendOptions =“6”。 Tomcat docs将channelSendOptions视为
One of the most important performance considerations is the synchronous versus
asynchronous replication. In a synchronous replication mode the request doesn't
return until the replicated session has been sent over the wire and reinstantiated
on all the other cluster nodes. Synchronous vs. asynchronous is configured using
the channelSendOptions flag and is an integer value. The default value for the
SimpleTcpCluster/DeltaManager combo is 8, which is asynchronous. You can read more
on the send flag(overview) or the send flag(javadoc). During async replication,
the request is returned before the data has been replicated. async replication
yields shorter request times, and synchronous replication guarantees the session
to be replicated before the request returns.
有没有人在此之前遇到过这样的问题和/或可以指导我做任何我可以尝试的事情？也可以改变channelSendOptions有帮助吗？
更新
我试着看看两只雄猫之间的连接是否正常工作＆amp;使用tomcat 2＆amp;的接收器端口（4010）进行netstat。 tomcat 1的进程id（13437） 给出以下内容。
netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java
tcp 0 580 ::ffff:192.168.x.x:41140 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
tcp 0 578 ::ffff:192.168.x.x:41136 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java
tcp 0 580 ::ffff:192.168.x.x:41146 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
tcp 0 826 ::ffff:192.168.x.x:41151 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java
tcp 0 757 ::ffff:192.168.x.x:41223 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java
tcp 0 580 ::ffff:192.168.x.x:41292 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
tcp 0 757 ::ffff:192.168.x.x:41286 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
tcp 0 578 ::ffff:192.168.x.x:41282 ::ffff:192.168.x.x:4010 ESTABLISHED 13437/java
tcp 0 1 ::ffff:192.168.x.x:41293 ::ffff:192.168.x.x:4010 SYN_SENT 13437/java
netstat -anp | grep 4010 | grep 192.168.x.x:4010 | grep 13437/java
我有两点意见：
a）连接数不断从0变为4。
b）发生此问题时，接收队列开始填写
观察'是'正常行为吗？有没有办法确定接收队列填满的原因？