12 Replies Latest reply on Mar 4, 2005 9:17 AM by Eugene Marko

    HTTP Session clustering intermittently

    Ray DeCampo Newbie

      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

        • 1. Re: HTTP Session clustering intermittently
          Ray DeCampo Newbie

          I forgot to mention that I am using JBoss 3.2.3.

          • 2. Re: HTTP Session clustering intermittently
            Juha Lindfors Master

            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.

            • 3. Re: HTTP Session clustering intermittently
              d_p2 Newbie

              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

              • 4. Re: HTTP Session clustering intermittently
                Juha Lindfors Master

                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.

                • 5. Re: HTTP Session clustering intermittently
                  Ray DeCampo Newbie

                  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.

                  • 6. Re: HTTP Session clustering intermittently
                    airsquig Newbie

                    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.

                    • 7. Re: HTTP Session clustering intermittently
                      Juha Lindfors Master

                      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..?

                      • 8. Re: HTTP Session clustering intermittently
                        airsquig Newbie

                        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.

                        • 9. Re: HTTP Session clustering intermittently
                          Juha Lindfors Master

                          Apparently HTTP session replication is supported only with sticky sessions.

                          • 10. Re: HTTP Session clustering intermittently
                            Juha Lindfors Master

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

                            • 11. Re: HTTP Session clustering intermittently
                              Matteo Regazzi Newbie

                              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

                              • 12. Re: HTTP Session clustering intermittently
                                Eugene Marko Newbie

                                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...