My tomcat application randomly invalidates the session information and the user if forced to log back in again. This only happens when the webapp is deployed with other specific web applications. When it is run by itself with no other app running, it works fine. There is a conflict somewhere, but I am unable to find it.
The webapp in question uses both the Spring and Hibernate frameworks. The other webapps do as well. Here is an example of what happens.
When I first log on, everything is fine.
JSESSIONID Matches
The JSESSONID matches in both the cookie and the management console. However, when using the application, it randomly terminates the session.
Session gone in Tomcat Console
When I another web request, the login page is shown and a new JSESSIONID has been generated.
From the research I have done, the JSESSIONID is generated whenever a JSP file is called and there is no current session. I don't understand why the session is being invalidated, but only when it is run alongside other applications. I have checked the memory usage, and I didn't notice a correlation between a memory drop and the sessions being invalidated. I guess that means that Tomcat isn't clearing sessions to free up memory.
Any help is much appreciated
Check that session.setMaxInactiveInterval() is not programmatically configured in the other web applications. This would elicit the behavior you describe.
This method is slightly different from the session timeout value that you would find in your web.xml files. (Here's a good rundown.)
the following steps may help you:
Are you sure that you did not override the default session time out value, Please check out your session time-out at runtime.
from tomcat manager page (~/manager/html/list) see the status of your web application sessions and press on the value of your app sessions column.
Related
I've got a system with multiple jboss (4.2.3) servers behind multiple apache servers.
In the situation where one of the jboss servers goes down we still get users with sessions for those servers coming in, however they "bounce" around the servers due to the application server ID in the JSESSIONID, causing apache to send the request to random servers for each request, resulting in session timeout errors.
My initial thought was to create an interceptor in the application to invalidate the session if we detect that the session is actually for a different server (i.e. session.invalidate())
But that doesn't cause a new JSESSIONID to be generated (even with the fix described here https://issues.jboss.org/browse/JBAS-4436)
My next idea was to create a valve to do the same job but on the Request instead of the HttpServletRequest, however I can't find the library to add ValveBase to jboss 4.2.3 (and I'm not even certain that valves are supported by 4.2.3)
Is there either:
a) Anything I've missed in getting one of my 2 ideas above to work
or
b) Any better ideas I haven't thought of for solving the problem ? (I would like to cluster the sessions but can't at the moment due to infrastructure problems)
Thanks.
Use Session Stickyness in Apache so it won't switch to other application server until it dies.
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.
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.
I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.
You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.
I'm debugging an issue where calls to our weblogic server often return with a new JSESSIONID value, replacing the JSESSION that was originally sent.
The issue occurs frequently, but not consistently. (Ie., when it affects you, it affects ~90% of your traffic.)
We've shown that the issue appears to be unrelated to the actual server call being made, which makes it hard for me to debug any specific method.
Is there a way to hook into the JSESSION creation in WebLogic, to see what is causing the session to be created / destroyed / invalidated?
Attaching a remote debugger would be great, but I'd settle for some form of logging that might point me in the right direction?
This is a standard part of the servlet spec (not WebLogic specific). You want the HttpSessionListener interface.
Note that the Servlet session stuff is really bad - the kind of behavior you're seeing can happen when memory problems kick in, etc. For a deconstruction, check out the presentation at SeaJUG (Rethinking Users and User Session Management). Slides and video are posted.
Nodemanager/WLST is something that is also useful in debugging and monitoring servers with Weblogic Admin, Enterprise Fusion Middleware Control, or Cloud Control.
We are running tomcat application server that handle over 100 concurrent sessions.
In the last 2 months the most active users noticed that sometimes they are getting kicked off from the system.
As I understood from the log tomcat sessions are getting expired without any reason.
I see no problems from the web application side.
Is there any problem from the tomcat side?
Tomcat 6.0.18.
If there has been no code change triggering this, I would look at memory usage. This might be the effect of Tomcat running out of memory and invalidating sessions to recover.
If at all possible monitor garbage collections, and/or put surveillance on with jconsole Java Flight Recorder or jvisualvm.
A possible cause is that you put in the session an object that does NOT implement the Serializable interface. Tomcat occasionally writes some of the sessions on the disk. If a session contains non-serializable objects it will simply be removed from the container (because of the NotSerializableException). If this is happening you should see the Exception in the tomcat log file.
I would increase the monitoring of the server in general and the sessions specifically.
A good monitoring application is lambda probe - it allows you to view the current sessions and their data. I would also add a HttpSessionListener to log session creation and destruction.
Edit
Is is possible that you add some non serializble objects to the session and Tomcat fails to passivate them to the disk?
Edit 2
Lambda probe seems to be dead, and there a much better fork of the project over at http://code.google.com/p/psi-probe/
there is a timeout, that you can configure in your web.xml:
<web-app>
...
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
</web-app>
use -1 for no timeout
Increase your logging of sessions, which may shed some light onto your problem.
The Tomcat config page's Logging in Tomcat includes an example of increasing logging of sessions.
We just ran into this with tomcat 6_0_18 and ibm 1.5 jvm
turns out it was an ibm jvm issue with atomic operations.
There is a fix in tomcats greater than 6_0_19 to handle it.
It also doesn't occur in sun 1.5 jvm
here are some more details
tomcat bugzilla case
I have seen similar problems when the following prerequisites exist:
multiple instances of the tomcat app are installed across multiple JVMs
load balancing (between the web server and the Tomcat JVMs) is not configured correctly.
Tomcat's session replication feature is not enabled
Due to the incorrect load balancing config, the web server may randomly decide to break session affinity and send an incoming request to a Tomcat JVM that has never seen the session before. The Tomcat JVM will issue a new session and the user will lose all of their previouS session data and effectively start over.
You can search Tomcat's bug database, but it would be better to have another look at your web application first. The chances that there is something wrong with Tomcat are very low.
Try to investigate what causes session invalidation. Are you using filters? Do you have cross-context requests? Try adding logging information for every request to find out, when exactly the session is lost.
I had a similar symptom (but more consistent). Users would sign in ok, go to the dashboard ok, then loose the session.
I realized I had done a Java 16 to 18 upgrade and had not recompiled everything. Cleaned (mvn clean) and recompiled the code for ALL my .jars/.war.
Problem solved, for me.
I hope this helps someone.
Eventhough I do not know the cause of the problem, one possible fix (which I had done at my previous project) would be to run the application on a tomcat cluster and have session failover. Sessions can be by default sticky and when one node goes down, the healthy nodes pick up the sessions and all this is transparent to the end user.