HTTP Session clustering intermittently

[raydecampo]

Hello,


(Yes, this is a long post; mostly because I have provided a lot of logging and configuration. Yes, you are busy and your time is valuable. Please take the time to scan over this post anyway and you will have my gratitude. Even a quick scan may provide the clue I need. Thanks!)


I have clustered two instances of JBoss on Windows 2003 servers. I get intermittent results with the HTTP session clustering. In order to test the clustering, I have my web server set up to alternate between the servers. I used the following JSP


<%@ page session="true" %>


<%
String key = "rkd";
String value = session.getAttribute(key) + " XXX";
%>
Session is true
Current value = <%=session.getAttribute(key)%>
Setting value to <%=value%>.
<%
session.removeAttribute(key);
session.setAttribute(key, value);
%>


<%
System.out.println("set to " + value);
%>



where I replaced XXX with the name of the server the JSP resides on. I would get results like the following for the value in the session:

Server X: "null XXX XXX XXX XXX XXX"
Server Y: "null XXX YYY YYY YYY YYY"

Clearly, there is some communication going on between the servers, otherwise I would not get intermixed XXX and YYY strings.

I noticed that there seemed to be a correlation between the problem and the appearance of the following in the log:

2003-12-15 12:28:09,146 INFO [org.apache.jk.common.ChannelSocket] connection timeout reached

However, it is not clear what timeout value I should twiddle.

The cluster-service.xml is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<!-- ===================================================================== -->
<!-- -->
<!-- Sample Clustering Service Configuration -->
<!-- -->
<!-- ===================================================================== -->





<!-- ==================================================================== -->
<!-- Cluster Partition: defines cluster -->
<!-- ==================================================================== -->



<!-- Name of the partition being built -->
DefaultPartition
<!-- Determine if deadlock detection is enabled -->
False
<!-- The JGroups protocol configuration -->


<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.3" mcast_port="45566"
ip_ttl="64" ip_mcast="true" bind_addr="SEE BELOW"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="true" />
<PING timeout="2000" num_initial_members="3"
up_thread="true" down_thread="true" />
<MERGE2 min_interval="5000" max_interval="10000" />
<FD shun="true" up_thread="true" down_thread="true"
timeout="2500" max_tries="5" />
<VERIFY_SUSPECT timeout="3000" num_msgs="3"
up_thread="true" down_thread="true" />
<pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
up_thread="true" down_thread="true" />
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="true" down_thread="true" />
<UNICAST timeout="5000" window_size="100" min_threshold="10"
down_thread="true" />
<FRAG frag_size="8192"
down_thread="true" up_thread="true" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true" />
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />




<!-- ==================================================================== -->
<!-- HA Session State Service for SFSB -->
<!-- ==================================================================== -->


jboss:service=DefaultPartition
<!-- Name of the partition to which the service is linked -->
DefaultPartition
<!-- JNDI name under which the service is bound -->
/HASessionState/Default
<!-- Max delay before cleaning unreclaimed state.
Defaults to 30*60*1000 => 30 minutes -->
0


<!-- ==================================================================== -->
<!-- HA JNDI -->
<!-- ==================================================================== -->


jboss:service=DefaultPartition
<!-- Name of the partition to which the service is linked -->
DefaultPartition
<!-- bind address of HA JNDI RMI endpoint -->

<!-- RmiPort to be used by the HA-JNDI service
once bound. 0 => auto. -->
0
<!-- Port on which the HA-JNDI stub is made available -->
1100
<!-- Backlog to be used for client-server RMI
invocations during JNDI queries -->
50

<!-- Multicast Address and Group used for auto-discovery -->
230.0.0.4
1102

<!-- IP Address to which should be bound: the Port, the RmiPort and
the AutoDiscovery multicast socket. -->
<!-- Client socket factory to be used for client-server
RMI invocations during JNDI queries -->
<!--attribute name="ClientSocketFactory">custom</attribute-->
<!-- Server socket factory to be used for client-server
RMI invocations during JNDI queries -->
<!--attribute name="ServerSocketFactory">custom</attribute-->




<!--
0
custom
custom
-->


<!-- ==================================================================== -->
<!-- Distributed cache invalidation -->
<!-- ==================================================================== -->


jboss:service=DefaultPartition
jboss.cache:service=InvalidationManager
jboss.cache:service=InvalidationManager
DefaultPartition
DefaultJGBridge




I left out the bind_addr for security reasons, however, it is a valid IP address which does appear in the output of "ipconfig /all". The cluster-service.xml on the other machine is identical, except for the bind_addr.

As for the jboss-service.xml in the tomcat WAR, I have tried:

interval <!-- you may switch to "interval" -->
1

and

instant <!-- you may switch to "interval" -->
2000

with identical results.

Here is the output from cluster.log:

2003-12-15 13:08:44,803 DEBUG [org.apache.jk.common.ChannelSocket] Setting maxThreads 75
2003-12-15 13:08:44,803 INFO [org.apache.jk.common.ChannelSocket] JK2: ajp13 listening on 0.0.0.0/0.0.0.0:8009
2003-12-15 13:08:44,803 DEBUG [org.apache.jk.common.ChannelSocket] Accepting ajp connections on 8009
2003-12-15 13:08:48,459 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Setting JGProps from xml to: UDP(bind_addr=xxx.xxx.xxx.xxx; ip_mcast=true; ip_ttl=64; loopback=true; mcast_addr=228.1.2.3; mcast_port=45566; mcast_recv_buf_size=80000; mcast_send_buf_size=150000; ucast_recv_buf_size=80000; ucast_send_buf_size=150000): PING(down_thread=true; num_initial_members=3; timeout=2000; up_thread=true): MERGE2(max_interval=10000; min_interval=5000): FD(down_thread=true; max_tries=5; shun=true; timeout=2500; up_thread=true): VERIFY_SUSPECT(down_thread=true; num_msgs=3; timeout=3000; up_thread=true): pbcast.NAKACK(down_thread=true; gc_lag=50; retransmit_timeout=300,600,1200,2400,4800; up_thread=true): pbcast.STABLE(desired_avg_gossip=20000; down_thread=true; up_thread=true): UNICAST(down_thread=true; min_threshold=10; timeout=5000; window_size=100): FRAG(down_thread=true; frag_size=8192; up_thread=true): pbcast.GMS(join_retry_timeout=2000; join_timeout=5000; print_local_addr=true;shun=true): pbcast.STATE_TRANSFER(down_thread=true; up_thread=true)
2003-12-15 13:08:48,474 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Creating
2003-12-15 13:08:48,474 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Creating JGroups JChannel
2003-12-15 13:08:48,631 INFO [org.jboss.ha.framework.server.ClusterPartition] Set the JGroups logging to log4j with category:org.apache.log4j.Logger@54ea79, priority: INFO, JGroupsLevel: 4
2003-12-15 13:08:48,631 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Creating HAPartition
2003-12-15 13:08:48,677 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Initing HAPartition: org.jboss.ha.framework.server.HAPartitionImpl@1af0b1
2003-12-15 13:08:48,677 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Initializing
2003-12-15 13:08:48,677 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setMembershipListener
2003-12-15 13:08:48,677 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setMessageListener
2003-12-15 13:08:48,677 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] create replicant manager
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] init replicant manager
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] bind replicant manager
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] create distributed state
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] init distributed state service
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] bind distributed state service
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] creating SubcontextHAPartition
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] done initing.
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.server.ClusterPartition] HAPartition initialized
2003-12-15 13:08:48,693 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Created
2003-12-15 13:08:48,724 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] Creating
2003-12-15 13:08:48,724 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] Created
2003-12-15 13:08:48,724 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateService] Creating
2003-12-15 13:08:48,740 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateImpl./HASessionState/Default] creating SubcontextHASessionState
2003-12-15 13:08:48,740 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateService] Created
2003-12-15 13:08:48,740 DEBUG [org.jboss.ha.jndi.HANamingService] Creating
2003-12-15 13:08:48,740 DEBUG [org.jboss.ha.jndi.HANamingService] Initializing HAJNDI server on partition: DefaultPartition
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.jndi.HANamingService] Create remote object
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.jndi.HANamingService] initialize HAJNDI
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.jndi.HAJNDI] subscribeToStateTransferEvents
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.jndi.TreeHead] registerRPCHandler
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.jndi.HANamingService] Created
2003-12-15 13:08:48,756 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Starting
2003-12-15 13:08:48,771 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Starting ClusterPartition: DefaultPartition
2003-12-15 13:08:51,287 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] ViewAccepted: initial members set
2003-12-15 13:08:51,287 INFO [org.jboss.ha.framework.server.ClusterPartition] Starting channel
2003-12-15 13:08:51,287 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] get nodeName
2003-12-15 13:08:51,287 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Get current members
2003-12-15 13:08:51,287 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 2
2003-12-15 13:08:51,287 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 1
2003-12-15 13:08:51,318 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] State was retrieved successfully
2003-12-15 13:08:51,318 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState called
2003-12-15 13:08:51,318 INFO [org.jboss.ha.framework.server.ClusterPartition] Started ClusterPartition: DefaultPartition
2003-12-15 13:08:51,318 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Begin AsynchViewChangeHandler
2003-12-15 13:08:51,318 INFO [org.jboss.ha.framework.server.ClusterPartition] Started jboss:service=DefaultPartition
2003-12-15 13:08:51,334 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] Starting
2003-12-15 13:08:51,334 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState for HAJNDI
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.jndi.TreeHead] unregisterRPCHandler
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.jndi.TreeHead] registerRPCHandler
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState for DistributedReplicantManager
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState for DistributedState
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState for HASessionStateTransfer
2003-12-15 13:08:51,349 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateImpl./HASessionState/Default] Receiving state of HASessionState
2003-12-15 13:08:51,349 INFO [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] Started jboss:service=ClusteredHttpSession
2003-12-15 13:08:51,396 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateService] Starting
2003-12-15 13:08:51,396 DEBUG [org.jboss.ha.hasessionstate.server.HASessionStateImpl./HASessionState/Default] HASessionState node name : 10.0.1.3:1099
2003-12-15 13:08:51,396 INFO [org.jboss.ha.hasessionstate.server.HASessionStateService] Started jboss:service=HASessionState
2003-12-15 13:08:51,412 DEBUG [org.jboss.ha.jndi.HANamingService] Starting
2003-12-15 13:08:51,412 DEBUG [org.jboss.ha.jndi.HANamingService] Create HARMIServer proxy
2003-12-15 13:08:51,412 DEBUG [org.jboss.ha.framework.server.HARMIServerImpl$RefreshProxiesHATarget] Invocation authorization called: ENABLE_INVOCATIONS
2003-12-15 13:08:51,443 DEBUG [org.jboss.ha.framework.server.HARMIServerImpl$RefreshProxiesHATarget] replicantsChanged 'HAJNDI' to 2 (intra-view id: 284403521)
2003-12-15 13:08:51,459 DEBUG [org.jboss.ha.jndi.HANamingService] Starting listener
2003-12-15 13:08:51,459 INFO [org.jboss.ha.jndi.HANamingService] Listening on 0.0.0.0/0.0.0.0:1100
2003-12-15 13:08:51,459 INFO [org.jboss.ha.jndi.HANamingService$AutomaticDiscovery] Listening on 0.0.0.0/0.0.0.0:1102, group=230.0.0.4
2003-12-15 13:08:51,459 INFO [org.jboss.ha.jndi.HANamingService] Started jboss:service=HAJNDI
2003-12-15 13:08:52,755 DEBUG [org.jboss.ha.singleton.HASingletonController] Creating
2003-12-15 13:08:52,755 DEBUG [org.jboss.ha.singleton.HASingletonController] Created
2003-12-15 13:08:53,240 DEBUG [org.jboss.ha.singleton.HASingletonController] Starting
2003-12-15 13:08:53,240 DEBUG [org.jboss.ha.singleton.HASingletonController] start HASingletonController
2003-12-15 13:08:53,240 DEBUG [org.jboss.ha.singleton.HASingletonController] partitionTopologyChanged, isElectedNewMaster=false, isMasterNode=false, viewID=284403521
2003-12-15 13:08:53,240 INFO [org.jboss.ha.singleton.HASingletonController] Started jboss.mq:service=HAILSingletonController
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Adding URL from spec: farm/
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] URL: file:/C:/jboss/jboss-3.2.3/server/all/farm/
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Added url: file:/C:/jboss/jboss-3.2.3/server/all/farm/
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] URL list: [file:/C:/jboss/jboss-3.2.3/server/all/farm/]
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Creating
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Scanner thread started
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Created
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Starting
2003-12-15 13:08:58,599 DEBUG [org.jboss.ha.framework.server.FarmMemberService] registerRPCHandler
2003-12-15 13:08:58,615 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Found 1 farmDeployments responses
2003-12-15 13:08:58,615 INFO [org.jboss.ha.framework.server.FarmMemberService] **** pullNewDeployments ****
2003-12-15 13:08:58,630 INFO [org.jboss.ha.framework.server.FarmMemberService] farmDeployment(), deploy locally: C:\jboss\jboss-3.2.3\server\all\tmp\cluster-examples-service.xml
2003-12-15 13:08:58,661 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Watch URL for: file:/C:/jboss/jboss-3.2.3/server/all/farm/cluster-examples-service.xml -> file:/C:/jboss/jboss-3.2.3/server/all/farm/cluster-examples-service.xml
2003-12-15 13:08:58,661 INFO [org.jboss.ha.framework.server.FarmMemberService] Started jboss:service=FarmMember,partition=DefaultPartition
2003-12-15 13:09:00,615 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Partition DefaultPartition received msg
2003-12-15 13:09:00,615 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] pre methodName: DistributedState._set
2003-12-15 13:09:00,615 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] handlerName: DistributedState methodName: _set
2003-12-15 13:09:00,615 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Handle: DistributedState._set
2003-12-15 13:09:05,411 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Partition DefaultPartition received msg
2003-12-15 13:09:05,411 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] pre methodName: DistributedState._set
2003-12-15 13:09:05,411 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] handlerName: DistributedState methodName: _set
2003-12-15 13:09:05,411 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Handle: DistributedState._set
2003-12-15 13:09:05,552 DEBUG [org.apache.jk.common.ChannelSocket] Accepted socket Socket[addr=skytrainii.ncf.navy.mil/155.252.138.162,port=2075,localport=8009]
2003-12-15 13:09:05,552 DEBUG [org.apache.jk.common.ChannelSocket] receive()
2003-12-15 13:09:05,552 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 0 4 = 4
2003-12-15 13:09:05,552 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 4 266 = 266
2003-12-15 13:09:05,552 DEBUG [org.apache.jk.common.ChannelSocket] Call next 0 org.apache.jk.common.HandlerRequest@32a4df
2003-12-15 13:09:05,599 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] getHttpSession called for session: +trGfa-RyD4M4i8FMmoDAA**
2003-12-15 13:09:05,630 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] setHttpSession called for session: +trGfa-RyD4M4i8FMmoDAA**
2003-12-15 13:09:09,646 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] setHttpSession called for session: +trGfa-RyD4M4i8FMmoDAA**
2003-12-15 13:09:09,646 DEBUG [org.apache.jk.common.ChannelSocket] send() 83 4
2003-12-15 13:09:09,646 DEBUG [org.apache.jk.common.ChannelSocket] send() 169 3
2003-12-15 13:09:09,646 DEBUG [org.apache.jk.common.ChannelSocket] send() 6 5
2003-12-15 13:09:09,646 DEBUG [org.apache.jk.common.ChannelSocket] receive()
2003-12-15 13:09:12,880 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Partition DefaultPartition received msg
2003-12-15 13:09:12,880 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] pre methodName: DistributedState._set
2003-12-15 13:09:12,880 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] handlerName: DistributedState methodName: _set
2003-12-15 13:09:12,880 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Handle: DistributedState._set
2003-12-15 13:09:14,848 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 0 4 = 4
2003-12-15 13:09:14,848 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 4 266 = 266
2003-12-15 13:09:14,848 DEBUG [org.apache.jk.common.ChannelSocket] Call next 0 org.apache.jk.common.HandlerRequest@32a4df
2003-12-15 13:09:16,848 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] setHttpSession called for session: +trGfa-RyD4M4i8FMmoDAA**
2003-12-15 13:09:16,848 DEBUG [org.apache.jk.common.ChannelSocket] send() 83 4
2003-12-15 13:09:16,848 DEBUG [org.apache.jk.common.ChannelSocket] send() 197 3
2003-12-15 13:09:16,848 DEBUG [org.apache.jk.common.ChannelSocket] send() 6 5
2003-12-15 13:09:16,848 DEBUG [org.apache.jk.common.ChannelSocket] receive()
2003-12-15 13:09:19,567 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Partition DefaultPartition received msg
2003-12-15 13:09:19,567 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] pre methodName: DistributedState._set
2003-12-15 13:09:19,567 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] handlerName: DistributedState methodName: _set
2003-12-15 13:09:19,567 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Handle: DistributedState._set
2003-12-15 13:09:20,833 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 0 4 = 4
2003-12-15 13:09:20,833 DEBUG [org.apache.jk.common.ChannelSocket] read() [B@1775bc 8192 4 266 = 266
2003-12-15 13:09:20,833 DEBUG [org.apache.jk.common.ChannelSocket] Call next 0 org.apache.jk.common.HandlerRequest@32a4df
2003-12-15 13:09:22,833 DEBUG [org.apache.jk.common.ChannelSocket] send() 83 4
2003-12-15 13:09:22,833 DEBUG [org.apache.jk.common.ChannelSocket] send() 225 3
2003-12-15 13:09:22,833 DEBUG [org.apache.jk.common.ChannelSocket] send() 6 5
2003-12-15 13:09:22,833 DEBUG [org.apache.jk.common.ChannelSocket] receive()
2003-12-15 13:09:22,833 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSessionService] setHttpSession called for session: +trGfa-RyD4M4i8FMmoDAA**
2003-12-15 13:09:42,832 INFO [org.apache.jk.common.ChannelSocket] connection timeout reached


I would appreciate any input or ideas.

Thanks,
Ray

[raydecampo]

I forgot to mention that I am using JBoss 3.2.3.

[juha]

It is not clear to me what your problem is or what is the result you expect.

The ChannelSocket timeout is configured in your tomcat-service.xml, it's the AJP13 connector timeout. It should not affect your state replication though.

[d_p2]

I also have this problem!

Here is my sample jsp:
<%@ page session="true" %>


<%
String key = "count";
Integer count = (Integer)session.getAttribute(key);
if ( count == null){
count = new Integer(1);
}else {
count = new Integer(count.intValue()+1);
}
session.removeAttribute(key);
session.setAttribute(key, count);
out.println("Count value: "+count.intValue());

for (java.util.Enumeration enum = session.getAttributeNames(); enum.hasMoreElements() ;) {
String name = (String) enum.nextElement();
out.println(name+" : "+session.getAttribute(name).toString()+"");
}
System.out.println(count.intValue());
%>



The output of our server:
server1:
2003-12-18 11:00:34,148 INFO [STDOUT] 7
2003-12-18 11:00:35,605 INFO [STDOUT] 8
2003-12-18 11:00:40,089 INFO [STDOUT] 9
2003-12-18 11:00:41,585 INFO [STDOUT] 10
2003-12-18 11:00:43,123 INFO [STDOUT] 11
2003-12-18 11:00:44,621 INFO [STDOUT] 12
2003-12-18 11:00:45,564 INFO [STDOUT] 13
2003-12-18 11:00:46,369 INFO [STDOUT] 14
2003-12-18 11:00:47,703 INFO [STDOUT] 15
2003-12-18 11:00:49,419 INFO [STDOUT] 16
2003-12-18 11:00:50,231 INFO [STDOUT] 17

server2:
2003-12-18 11:00:21,431 INFO [STDOUT] 1
2003-12-18 11:00:25,914 INFO [STDOUT] 2
2003-12-18 11:00:27,147 INFO [STDOUT] 3
2003-12-18 11:00:29,875 INFO [STDOUT] 4
2003-12-18 11:00:30,817 INFO [STDOUT] 5
2003-12-18 11:00:31,795 INFO [STDOUT] 6
2003-12-18 11:00:32,700 INFO [STDOUT] 7
2003-12-18 11:00:50,997 INFO [STDOUT] 8
2003-12-18 11:00:52,809 INFO [STDOUT] 9
2003-12-18 11:00:53,980 INFO [STDOUT] 10
2003-12-18 11:00:55,500 INFO [STDOUT] 11

We expected the server2 will set the count=17 instead of 8

best regards,
dp

[juha]

You're both removing the old attribute from the http session rather than just rebinding a new value to an existing attribute, why are you doing that?

It's still not clear to me what you're trying to achieve.

[raydecampo]

I know that I added in the remove call in the hopes that it would trigger whatever magic needed to be done to get the replication going. I suspect the other poster did the same.

Let me try to clarify what we are trying to do. We have a web server (Apache with mod_jk) set up to do load balancing between two JBoss servers. The JBoss servers are clustered and should be sharing the HTTP session. The web server is set up to do round robin load balancing. So the first request goes to JBoss X, the next to JBoss Y, etc. Ultimately the goal is that the HTTP session is replicated and it does not matter which JBoss server serves any given request.

The HTTP session did not seem to be shared in my actual application, so I created the JSP to try to reduce the problem to its smallest form. The JSP adds the server name to a value in the HTTP session. If clustering is working properly, when I access the JSP via the web server repeatly I would see a sequence of alternating names. Instead the name changes once and then it seems like the servers never update the session to the other server. I see a sequence like:

XXX
XXX YYY
XXX XXX
XXX YYY YYY
XXX XXX XXX

where I would expect:

XXX
XXX YYY
XXX YYY XXX
XXX YYY XXX YYY
XXX YYY XXX YYY XXX

We have tried a few versions of JBoss (3.2.3, 3.2.4RC1 and 3.2.1) to no avail.

Thanks for your input.

[airsquig]

Hello All,

I was having this problem as well. I have replicated it in the way described above. I did some code tracing and found the following:

It seem that the tomcat ClusterManager has a local session cache. If the session is not in the cache, it will access the HTTPSessionMBean, which calls the Appropriate EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A.

Now, Once both nodes have the session in their cache, The manager does not appear to go back to the MBean to re-get their session, it just uses the cached version. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes the scenario mentioned above.

It does look like each node is updating there version in the EJB but, it is off because it is based off of the cached node, it is invalid.

Example, If on every server hike, we append the node name to string in the cache, in a round robin situation, we would expect

Node A Node B
A
AB
ABA
ABAB
ABABA ...

Instead, we get the following:
Node A Node B
A
AB
AA
ABB
AAA
ABBB
Again, I have not fixed this, I can just see the issue. Any input from people more familiar with the code would be welcomed.

[juha]

Ok the caching thing does smell like a bug. I'm a little suspicious about the removeAttribute() calls but maybe that's not related.

It might have gone unnoticed as most people use affinity in their sessions. Please submit as a bug on the SourceForge and you'll get someone to look at it. I'm assuming you made the necessary changes to your web.xml to enable session replication..?

[airsquig]

This issue has been raised as a bug at sourceforge as bug ID 63113.
If you are stuck, you can where in the code this occurrs under the bug report.

[juha]

Apparently HTTP session replication is supported only with sticky sessions.

[juha]

There's now a resolution to BUG ID#863113 committed to 3.2 branch by Thomas Peuss.

[mregazzi]

Hi all,

I have the same problem, but I think that if you talk about session replication you cannot talk about sticky session. The replication should be between nodes, so you can set up fault tolerant configuration.
I wrote two stupid JSPs, the firsts that put a string in session, the second that get it back. Obviously, due to round robin scheme for load balancing, you open the first page on server 1 (the page loads the string on server 1 session) then you open the second page on server 2 but you have a nice NULL. Apache seems to be well configured, the clustering merging seems to be done, the modjk2 is configured well, the tag is present on my web.xml.
May be I missed something. I'm running JBoss (MX MicroKernel) [3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445)] on 2 windows 2000 pro, downloaded 15 days ago (I'm going to check out the cvs module or just check for a new build).
Thank you very much in advance, and sorry for bad English.
Matteo

[markoh]

Hello

Have something like this
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=61029
Solved with changing
..all/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml

...
<attribute name="UseLocalCache">false</attribute>
...

Jboss 3.2.5

But for me works only when BASICAuth or no auth used...