Troubleshooting: HTTP Session Replication Failure Issues

One of the major advantage of weblogic server is 'HTTP session replication'. Sometimes, HTTP session states are not replicated from the primary server to the secondary server. This is the most common issue which is observed.

Symptoms:

1. The application using HTTP session does not function as designed and you see a loss of session data.
2. You might be asked to re-log into the application even when the session has still not timed out.
3. You see errors and warnings related to HTTP session failures in the server's log file.
4. The request is not failed over to another server properly.

There are several reasons as to why session replication fails. We will look at ways to diagnose the issue, possible reasons for it, and the ways to address them.

Types of HTTP Session Replication
There are five different implementations of session persistence:

• Memory (single-server, non-replicated): When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart WebLogic Server.
• File system persistence: Session information is stored in a file under the PersistentStoreDir specified.
• JDBC persistence: Session information is stored in a database table.
• Cookie-based session persistence: Session information is stored in a cookie.
• In-memory replication (across a cluster): Session data is copied from one server instance to another into memory.

Usually observed causes session not getting replicated:

1) All application objects are not serialized
2) Session is not set using set.attribute()
3) Network issue causing the managed server to move out of the cluster.
4) Weblogic server hang resulting to non-responsiveness to replicated session
5) Issue at the webserver end.

Diagnosing the Issue
Consider a scenario with two servers (MyServer-1, MyServer-2) in a cluster. When you enable the debug flags (see the "Enable the Debug Flags to Track Session Replication Failures"section), you will see the messages below when a request from a client is sent the very first time.

On MyServer-1:

<000000>

<000000>

This logging message means that the primary server is MyServer-1 and a secondary has been created on MyServer-2. A message like the one shown below will be logged on MyServer-2 to confirm that.

ExecuteThread: '1' for queue: 'Replication'> <>
<000000>
####

<> <000000>

If you check the JSESSIONID it looks like:

JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj
!-1587343083!-1587348922

JSESSIONID is the default name of the cookie, which could be changed to anything in weblogic.xml. The format of JSESSIONID is

SessionId!PrimaryServer JVM Hash!SecondaryServer JVMHash

Every time data is changed (either set/get or removed) in the session you'll see the logging message.

On MyServer-1:

<000000>

On MyServer-2:

####
<> <000000>

If for any reason session replication fails, you will see the message below in the MyServer-1 log:

<000000>

<000000>

And, the JSESSIONID would appear as

JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj!-1587343083!NONE

The secondary server hash would become NONE

Enable the Debug Flags to Track Session Replication Failures
You can enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.