views:

160

answers:

2

Hello,

I have a question about session management. Here's the scenario.

There are 3 groups of users on the same network. There is a J2EE application that is set to end a user's session after 60 minutes. The groups are A, B and C. Now Group A, B and C all log into the J2EE application and start using it. Group A users can use the application just fine with no issues. Group B and C though are kicked out are various times, but all before the set time of 60 minutes. Now a user from Group A goes to a Group B's PC. The Group B user logs into their PC with their AD credentials and then the Group A user logs into the J2EE application. After some time, well before the 60 minute session time, the Group A users' session is ended prematurely.

Still with me? I hope so.

Now the Group B user, goes to a Group A users' PC and does the same as above. The Group A user logs into their PC with their AD credentials and the Group B user logs into the J2EE application. The Group B user has no timeout issues and doesn't get kicked out before the 60 minute set time for the session to end.

Whew! So it doesn't look like the J2EE application is terminating the users' session, because the Group B users is fine when logged into a Group A users PC.

Now, would someone be able to explain how this could occur? I was thinking that the Application Server (Websphere App Server 6.1) might be configured to do such a thing, but I'm not a websphere administrator.

Any ideas or suggestions of what I may try to solve this issue would be greatly appreciated. Also, please ask any questions as I know that there may be some things that I have left out in my explanation of what is going on.

Thanks!

A: 

Are you setting HttpSession.setMaxInactiveInterval(int secs) in your code. This overrides any other settings in WebSphere. maybe you have a random value that is being set ?

Romain Hippeau
@Romain Hippeau - I checked the HttpSession.setMaxInactiveInterval(int secs) and it's only used in 1 place and the value is not a random value. It's set to 3600 seconds (60 minutes).
Ruepen
A: 

Besides trying the suggestion provided by Romain also try this. You can print the contents of HTTPSession (and its attributes) and see what the values are.

Use HTTPSessionListener and you would be notified when sessions are created and destroyed.

This would tell you when the sessions are getting destroyed.

It is likely that something in the application might be triggering it.

It is too difficult to say what are the possible problem and we can take a initial stab at these approaches.

HTH Manglu

Manglu
@Manglu - I will try what you have suggested during our next scheduled deployment in our production environment. But how would you explain the fact that it only happens to Group B and C, but Group A isn't kicked off before the 60 minutes? They are all hitting the same application. Please read my the details again and you will notice that when a user from Group B logged into the application using a Group A users' PC, he wasn't kicked off before the 60 minutes. Doesn't that seem like it would be network related? Something perhaps the way the Group A's PC is configured?
Ruepen
@Ruepen,I would inspect the HTTP Headers and see the LTPA token and HTTP SessionIDs that are sent across in every call and see when the HTTPSessionID is no longer sent back by the server.This effectively creates the impression that you are kicked out by the server. By looking at the server side, and looking for htese session IDs from Group A's PC you will be able to come to reasonable conclusions.Network should not be selectively removing some HTTP Header info. I am not stating that network is not the culprit but it less likely to be.
Manglu