3 Replies Latest reply: Oct 8, 2014 4:09 AM by Radu Dobrinescu RSS

    Session state replication taking time to replicate in weblogic cluster

    user13298733

      I have a application fully serialized code with WEB-INF/lib containing the below configs with Unicast communication.


      <?xml version="1.0" encoding="ISO-8859-1"?>

      <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

       

       

      <weblogic-web-app>

        <session-descriptor>

          <session-param>

            <param-name>TimeoutSecs</param-name>

            <param-value>1800</param-value>

          </session-param>

                      <cookie-http-only>false</cookie-http-only>

        <persistent-store-type>replicated_if_clustered</persistent-store-type>

                      </session-descriptor>

      </weblogic-web-app>

       

      OHS plugin is having below config

       

      LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

       

      <IfModule mod_weblogic.c>

      WebLogicCluster 172.12.113.141:7006,172.12.113.140:7006

              MatchExpression /finapp/*

      </IfModule>

       

      And weblogic cluster is replicating session instantly when ever there is some activities happening in the application.

       

      It is having a problem only in below scenario when the session is open but the user is not doing anything.


      I have 2 nodes in the cluster if one goes down(currently request serving one) it is failing over to the next but the session is not getting copied instantly. Below is the scenario where it works fine and where the replication is delayed.

       

      1. Both servers(server1,server2) up for some time and user logs in and is continuing work.

      2. primary server(server1) crashes in middle, secondary(server2) will take over the existing session and you will see user will be continuing the work without any issues(no logouts).

      3. After sometime server1 comes up online, user keeps on testing(clicking some tab which makes a request to server), you will see the server1 will have a replica of server2 instantly.

      4. You can bring down the server2 now and you will see the users session will not interrupt and user will be able to continue session with the server1.

       

       

      Now coming to the scenario where you will be able to delayed replication :

       

      1. Both servers up and user logged in and started work.

      2. Primary server(server1) goes down and secondary server(server2) will take over the session and let the user continue its work without any logout.

      2. server1 comes back online and user is not doing anything(no clicks) with application just kept the session open and server2(primary session) goes down within the replication time then the user will get logged out and might see some erratic behavior in any applications deployed to that weblogic. (We saw that if we dont shutdown server2 immediately(within 1min) and wait for 5mins+ weblogic is copying  the session from server2 to server1. After that copy if we shutdown the primary server(server2) user is not having any issues)

       

      To summerize if a session is active(logged in) and some activity(clicking) is going on then replication is happening instantly from primary to secondary but if the user is active(logged in) and not doing anything(not clicking) then the session from primary to secondary is taking 5minutes+

       

      Please let me know if there is some weblogic configs to check to reduce this time lag and let weblogic copy the session continuously either the user is performing any activity or not in the logged in session.


      Thanks,


        • 1. Re: Session state replication taking time to replicate in weblogic cluster
          user13298733

          Hi All,

           

          Any help on the same much appreciated. Is it a bug or default behavior of weblogic session replication or anything can be done to force replicate the ideal no activity session instantly like it gets replicated on clicking anything on the session.??

           

          I tried to reduce heart beat rate but to no avail.

          • 2. Re: Session state replication taking time to replicate in weblogic cluster
            user13298733

            Is this forum dead? or no body answering?

             

            Shall I post it in some other forum?

            • 3. Re: Session state replication taking time to replicate in weblogic cluster
              Radu Dobrinescu

              Hi,

               

              This is the expected behavior. Please take a look at this document: WebLogic Server - Session Replication/Failover Scenario When Only One Server In Cluster is RUNNING (Doc ID 1292033.1)


              In a WebLogic Server domain, with a Cluster of 2 Managed Servers and a web application deployed on this Cluster, you have only one managed server running and then you make a request through a proxy server to access the application.

              The default cookie which is JSESSIONID will be created something like

              <SessionID>!<PrimaryJVMID>!NONE

              Here, you see the secondary server as NONE as there is only one server in cluster running.

              Now, you leave HTTP session idle, meaning there will be no activity and requests in it.

              Now, you bring up the second managed server instance in the cluster. The JSESSIONID for the earlier created HTTPSession will be unchanged: still

              <SessionID>!<PrimaryJVMID>!NONE

              unless there are any requests made or activity in it.

              At this point of time, if there is a failure of the Managed server, the idle in-flight HTTP Sessions which were created earlier when this managed server was RUNNING, will be dropped and there will be no failover. Only active HTTP Sessions which have a secondary JVM ID will be failed over to the secondary managed server.

              At any point, if subsequent requests are made and if any activity is made to the Idle HTTP sessions which were earlier created, the JSESSIONID gets updated with the secondary JVMID and sessions gets replicated and failed over in case of server crash.