Geek Answers Handbook

Weblogic session cookie modifies primary and secondary servers

We have weblogic configured in 2 managed server clusters. Requests go through a load balancer that (presumably) has been configured for sticky sessions. However, our requests bounce between managed nodes, as if sticky sessions were not configured.

One thing I noticed is that the JSESSIONID cookie sometimes replaces the hashes of the primary and secondary servers. They must remain unchanged throughout the user's session.

eg. we see

Request 1, JSESSIONID=ABCDEFG...!SERVER1HASH!SERVER2HASH Request 2, JSESSIONID=ABCDEFG...!SERVER2HASH!SERVER1HASH Request 3, JSESSIONID=ABCDEFG...!SERVER1HASH!SERVER2HASH

And sometimes we even see that the hash is set to "NONE", as if this member of the cluster is no longer there:

 Request 4, JSESSIONID=ABCDEFG...!SERVER1HASH!NONE

Does anyone know why primary and secondary servers will switch this way?

+4
source share
2 answers

In cases where we have encountered in the past, this is a problem in the load balancer , where it cannot or cannot recognize the session as sticky with server 1 and switches it to Server 2. This behavior is more pronounced with heavy traffic.

Once (around 2003 on Weblogic 6.1) this happened because Cluster multicast address had the pattern x.0.0.1

After a very long study with BEA representatives, this turned out to be a source of trouble. This led to the updating of BEA public documents to explicitly indicate

Do not use multicast x.0.0.1 address where x is between 0 and 9, inclusive

+3
source

We also encountered this problem when the JSESSIONID cookie was changed (in weblogic.xml), when another web application appeared in it, but the Apache Weblogic plugin used WLCookieName by default.

0
source

More articles:


All Articles