We are facing Performance issues with the Tomcat server.
I have one question about Tomcat Sessions. When the user logs in, a session will be created by the Tomcat. The session will be invalidated once the user clicks on log out link.
If the user is idle for some period of time and the session time out limit exceeds, then, if the user does some operation on the same session. then, the session will be expired.
What will happen, if the user closes the browser window without log out? What will happen to the session? Would it be cleaned up by GC after some time or would it be accumulated on the heap in inactive mode. I suspect, this is the issue with our production system. Please can somebody explain this scenario and possible fix for this?
Thank you William for your reply. I will give more details now.
What we are doing is: When ever any user logs in, we are storing his session details on DB. If he click on log out link, then, we are calling session.invalidate method which triggers User Counter Listener to call, where we are deleting the session from DB.
My assumption is, when ever the Tomcat server calls invalidate method on any session, the user counter listener class will be invoked as it implements HttpSessionAttributeListener interface. in Attribute removed method, we are deleting the Session information from DB.
Now, What I observed is, if the user closes the window without log out, the session information is present on the DB though the time out period expires!! Can I assume from this that the session is already existed on memory?
Please note, we have configured the session time out period on web.xml file.
HTTP is not like client/server. In a client/server app, you open a network connection, do your work, and then disconnect/terminate.
In HTTP, each time you send a URL, it opens a network connection, sends data, listens for a reply, and then closes the connection. It doesn't keep any connections open for the life of the application, only the life of a request/response cycle.
That's one of the reasons for HttpSession. Since each request is effectively unrelated to any other request, the HttpSession stores context that requests can reference in order to give the illusion that you're running a continuous session. However, it's only an illusion. If you navigate off a page or exit your browser, the only way the server will know that you've effectively logged out is that you don't send any more requests. After a certain length of time, the server will eventually destroy the session objects in order to free up resources. Closing a browser window doesn't send any requests to any of the servers that the browser may have recently communicated with, nor does shutting down the browser.
The HttpSession will exist on the server until it's either explicitly invalidated or until the session timeout has been reached. At that time, if there are any session listeners installed, they will be notified of the session destruction event. Whether the HttpSession exists in memory or somewhere else will depend on what server software you're running and how it was configured.
Sometimes the only way things ever got fixed is because people became uncomfortable.
I understand what you said. Just tell me what will happen in the below case:
A session object has been created on the memory. User closes the window without performing the log out action. So, there will not be any communication from client(Browser) to this session object.
Would there be any thread running on Tomcat server which checks every session object and cleans it if the session time out period for a particular session object exceeds (or) The session object waits till some communication happens to it indefinitely (May be till next server restart in which case all objects on the memory will be deleted)
Yes, Tomcat will have a Thread checking sessions for timeout - thats the whole idea, the container manages sessions.
I am curious as to why you are getting involved with DB storage of session data? Seems to me you should use either the built in session management OR a DB - what is the thinking behind using both? Seems to me that is leading to a tangle of responsibilities.
Also - why HttpSessionAttributeListener when what you want is a sessionDestroyed event as per HttpSessionListener - destroying the session does not have to activate any of the attribute listener events - that would depend on the implementation.
Thanks for your reply. I must admit that tomcat do destroy the inactive sessions after expiration. What I have done is, implemented Session Listener interface and in session destroyed method, I placed a log statement. After some period of time, I found a log statement saying session was destroyed. Thanks for your help on this.