Weblogic session cookie is changing primary and secondary servers

We have weblogic set up in a 2 managed 开发者_如何学Pythonserver cluster. Requests go through a load balancer that (supposedly) has been configured for sticky sessions. However, our requests are getting bounced between the managed nodes as if sticky sessions are not configured.

One thing I noticed is that the JSESSIONID cookie is occasionally swapping the primary and secondary server hashes. They should remain the same throughout the life of the user's session.

E.g. we are seeing

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

And sometimes we are even seeing the hash's be set to "NONE", as if that member of the cluster is no longer there:

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

Does anyone know why the primary and secondary servers would switch like this?

In the cases we've come across in the past, it's a problem at the Load Balancer, where it does not or cannot recognize the session as sticky with Server 1 and switches it to Server 2. This behaviour is more pronounced at heavy traffic.

On one occasion (circa 2003 on Weblogic 6.1) , it was because the Cluster multicast address was of the pattern x.0.0.1

After a very long investigation with BEA folks, this was found to be the source of the problem. This resulted in the public BEA docs being updated to explicitly state

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

We also had this issue when the JSESSIONID cookie was changed (in weblogic.xml) when another web-app came online, but the Apache Weblogic plugin was using the default WLCookieName.