5 Replies Latest reply on Aug 10, 2019 7:32 AM by Stefan Hall

    Midtier - Trouble with Session Affinity (Sticky bit) - need the opinion of a loadbalancer expert

    Stefan Hall
      Share This:

      We have a little stress with our affinity session and I would like to discuss with you the advantages and disadvantages of different approaches.

       

      Our Loadbalancer admins attach great importance to a continuous load distribution and control of session affinity via the application. I.e. if a user logs off correctly, then his next access should be able to be distributed according to the load.

       

      Basic system: 2 Midtier, 1 LB with enabled sticky

       

      Variant 1 (our current one) - sticky about the jsessionid

      Pro: ID is unique and the application controls the binding to a specific midtier. If the user logs off, the binding ends and the LB can redistribute the next access.

      Con: If the user calls the application several times in different tabs, he can land on both midtiers and would be on the move with two jsessionids. If rsso comes into play and a midtier detects a normal timeout (no activities für 60 min at one tab), the user is logged out of the RSSO and has no session left in either Tab!

       

      Variant 2 - sticky over the client IP

      Pro: ID is unique and no matter how many tabs are opened, the user always lands on the same midtier.

      Con: There is no real load distribution during the day or longer, because the IP is always the same and the user always lands on the same midtier, even if he has logged off in the meantime.

      The application can't cleanup the loadbalancer ip-midtier table.

       

      Variant 3 - embroider over LB cookie (apparently BMC recommendation?)

      Pro: ID is unique - I don't know different tabs works?

      Con: The LB cookie must have an expiration time,

        - if you choose this like the LB timeout, then you get a timeout after this time in any case, because the LB cookie is invalid and the LB can redistribute independently of a still valid jseesionid

        - If the xpiration timeis set very long (8-10 hours), there is no load balancing, as with the IP-based solution.

       

      Which way do you go and how do you solve the problem with the cookie runtime if you follow the BMC recommendation? As far as I know, the runtime of a cookie cannot be adjusted dynamically by the LB.

       

      So, now we are totally curious.