From what I understand, it used to contain the IP as part of the 'key'...but because of DHCP scenarios, that was changed many years ago....
I don't know the exact mechanism, and my users don't experience it much...so I historically don't worry about it much....BMC seems reluctant to give the exact formula, more than likely because if they do it'll be possible to 'fake it'
i assume that "user is currently connected..." and the GUID details are not to be revealed by BMC, right?
What's really interesting G cookie is browser-dependend while GKW cookie is not. Do you know something about GKW cookie?
Understanding this whole mechanism would help me troubleshoot the issue my users are experiencing.
Beside "user is currently connected..." my users are facing another issue related to sessions. Sometimes all of the sudden, during normal Remedy activity, they're receiving "session has expired" notification and they have to reload whatever they did in order to continune working. I've checked LB (ACE, set to cookie-insert), MT (tomcat) and SSO (JSS) and it looks like all settings (timeouts) are set correctly. Any ideas what can be causing this strange behaviour?
I'm thinking about switching LB cookie-insert to cookie dynamic learn and set stickyness to G cookie. Any thoughts about that one?
You are delving deeper into this than I ever have....sorry I can't be of much help.
We faced similar issues when we first migrated over to the Barracuda Load Balancer in Server Group.
The fix was as you mentioned "Sticky Session", i think you can continue to use cookie-insert itself.
This will most probably solve both of your issues cause what might be happening is the user is connected to a session & since the sticky session is not set a new session might be established but the old session is not let go properly from the server & the system thinks that the user is already connected from a different machine. I dont know the details on how Remedy identifies & manages each sessions & cookies.
Hope this helps.
the thing is... we've load balancer configured to use cookie-insert sticky session already.
Cookie insert—The ACE inserts the cookie on behalf of the server upon the return request, so that the ACE can perform cookie stickiness even when the servers are not configured to set cookies. The cookie contains information that the ACE uses to ensure persistence to a specific real server [Server Load-Balancing Guide vA3(1.0), Cisco ACE 4700 Series Application Control Engine Appliance - Configuring Stickine…
Other way to perform sticky session is Dynamic cookie learning (we're planning to test it shortly - and if possible set it to learn "G" cookie):
Dynamic cookie learning—You can configure the ACE to look for a specific cookie name and automatically learn its value either from the client request HTTP header or from the server Set-Cookie message in the server response. Dynamic cookie learning is useful when dealing with applications that store more than just the session ID or user ID within the same cookie. Only very specific bytes of the cookie value are relevant to stickiness. [Server Load-Balancing Guide vA3(1.0), Cisco ACE 4700 Series Application Control Engine Appliance - Configuring Stickine…]
but let's say that changing the way that LB handles stickyness will not help us solving the issue... what should we check on MT, Tomcat, AP, JSS? Any suggestions?
Hmm... I hope may be the dynamic cookie learning method helps. If not what i would do is keep only one AR Server active in the Server Group & also have the load balancer set to check for only for that single AR Server you have kept alive & see if that resolves the issue. This will confirm that the Load Balancer is somehow not keeping the same session.
If a single server model resolves the issue, i will check the Load Balancer Logs & see if they can find something there.
You can always cross check you have followed all the steps & configuration from the Remedy side for the Server Grouping.