Question

In my web app, when a user logs in, I add his Id to a vector of valid Ids in the servlet, when he logs out, I remove his Id from the vector, so I can see how many current users are active, if a user forgets to log out, my servelt generated html has :

<meta http-equiv='Refresh' content='30; url=My_Servlet?User_Action=logout&User_Id=1111'> 

in the tag to automatically log him out.

But I’ve noticed many users are there for ever, never logged out. I found out why, by closing their browsers, they never manually or automatically logged out, so their user Ids will never be removed from the valid user Ids vector.

So, my question is : how do I detect users closing their browsers, so my servlet can remove their Ids from the vector ?

---

I see some light at the end of the tunnel, but there is still a problem, my program has something like this :

Active User List :

User_1 : Machine_1 [ IP_1 address ] User_2 : Machine_2 [ IP_2 address ] User_3 : Machine_3 [ IP_3 address ] ... 

How do I know, from the session listener, which user’s session has ended and therefore remove him from my list?

I was hoping when the session ends, the HttpServlet’s destroy() method would be called and I can remove the user Id in there, but it never gets called when user closes his browser, why? And is there any other method in the HttpServlet that gets called when a session closes?

Answer 1

There is no way to know on the server-side (unless you are using some JavaScript to send a message to the server) that the browser has closed. How could there be? Think of how HTTP works – everything is request and response.

However, the application server will track when Sessions are active and will even tell you when a Session has been destroyed (such as due to time-out). Take a look at this page to see how to configure a HttpSessionListener to receive these events. Then you can simply keep track of the number of active sessions.

The number of active sessions will lag behind the actual number of current users, since some period of (configurable) time has to elapse before a session is timed out; however, this should be somewhat close (you can lower the session-timeout to increase the accuracy) and it is a lot cleaner and easier than 1) tracking Sessions yourself or 2) sending some asynchronous JavaScript to the server when a browser is closed (which is not guaranteed to be sent).