Tracking HTTP Session Replication Failures In Weblogic Cluster
Today we will learn
how to trace HTTP session replication failures in Weblogic cluster. Sometimes,
HTTP session states are not replicated from primary server to secondary
server.There are several reasons for session repllication failures like
application using HTTP session does not function properly as designed and leads
to loss of session data. We may see lot of HTTP failure error ans warning in
server log files. There are several ways to debug the HTTP session failures and
some of them are below ..
If Apache is used
as load balancer, enable the debug perameter on in httpd.conf file and logs
will generated in/tmp/wlproxy.log
Use the
weblogic.Admin command-line utility to dynamically turn the debug options on
and off as below :
java weblogic.Admin
-url t3://localhost:7001 -username weblogic -password weblogic SET -type
ServerDebug -property DebugCluster true
Alternatively, we
can edit the config.xml and the perameter each server that
you want to debug and set it to “true” to enable or “false” to disable. Then
restart the Admin Server. Managed Servers will reconnect to the Admin Server and
the debug flags will then dynamically take effect.
For example:
At the end, with
all the flags set, in your config.xml the ServerDebug tag would look like:
DebugReplication=”true” DebugReplicationDetails=”true” Name=”MS1″/>
Make sure the
stdOutSeverity level of the server is INFO and StdoutDebugEnabled is set to
“true”. The debug information will be logged into the server log as well as to
the standard out.
Now we will learn how to understand a debug log file, in MS1 log file
10.18.24.98:
[8088,8088, -1, -1,8088, -1, -1]: TD1: MS2>
It means that the
primary server is MS1 and a secondary has been created on MS2. A message like
the one shown below will be logged on MS2 to confirm that.
ExecuteThread: ’1′
for queue: ‘Replication’> <>
<000000>
####
’1′ for queue:
‘Replication’>
If you check the
JSESSIONID it looks like:
JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj
!-1587356342!-1587878545
JSESSIONID is the
default name of the cookie, which can 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 MS1:
On MS2:
####
’1′ for queue:
‘Replication’> <> <000000>
If for any reason
session replication fails, you will see the message below in the MS1 log:
10.18.24.98:
[8088,8088, -1, -1,8088, -1, -1]:TD1:MS2>
And, the JSESSIONID
would appear as
JSESSIONID=1E9Xwn7nLYfOsc1obgRZIwW5s72an7HPPvSD7iaWHMXzpHga5cQj!-1587356342!NONE
The secondary
server hash would become NONE and we can configrm session data is lost
and HTTP session replication failure.