Home/ Questions/Q 3609226
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T21:36:00+00:00

We have weblogic set up in a 2 managed server cluster. Requests go through

  • 0

We have weblogic set up in a 2 managed server 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0