Reputation: 75
We are experiencing a strange behaviour, we have an application (jsf 2.2.4 embedded) that has a login form, glassfish has sso enabled and a custom realm (LDAP). We have also several applications (some with jsf 2.2.4 embedded, others using jsf implementation of glassfish) that are linked by the application that contains the login form.
For some reason when glassfish has created 300 - 400 sessions approximately or cpu is at high rate or maybe at a random moment, and we navigate from the main application to the others and then return to the main application, at some point glassfish changes the jsessionidsso cookie, assigning a new one. The thing is that sometimes that cookie represents the session of another user, so thats where we have a session mix and can see the information of another user.
We are running Glassfish-3.0.1 on a Centos-6.5, no proxy.
We have already tried updating weld following this guide http://www.andygibson.net/blog/quickbyte/updating-weld-in-glassfish-v3/ but we are currently experiencing the same behaviour.
Can someone point us to the right direction? What could it be?
Thanks so much! Regards, Mateo.
Upvotes: 1
Views: 525
Reputation: 31
We have the same problem and don't know the reason yet. Our temporary solution: we attach the user ID to every user request and we check the permissions of that particular user every time, because we unfortunately can not trust to the session id. If the session does not belong to the user ID, we reject the request and ask the user to initiate a new session. The problem affects less than 1 percent of sessions.
We suspected the load ballancer system in front of the Glassfish servers, but if someone has the same experience without load ballancer layer, the problem hides somewhere else.
Upvotes: 1