Subject: Re: Usage of ContainerServlet 2007-11-01 - By Christopher Schultz
Back
-- --BEGIN PGP SIGNED MESSAGE-- --
Hash: SHA1
Mike,
Wizard of OS wrote:
> During a day we have several hundred users which could produce 15-20
> session per user.
Ouch.
> Session timeout is set to 11 hours which is part of
> work contract limitations.
OUCH!
> This can't be changed. Every session can
> have a few hundred kilobytes but that number isn't certain because we
> didn't make a complete test yet. The issue basically is that we have
> to track what users do to track down errors during some processes and
> avoid maintance clutter by zombie sessions.
Hmm.
> I hope this made it clearer.
Yes, it makes it much clearer.
So, you have several options. My personal recommendation (and the only
option I'll cover) is a do-it-yourself approach. Working with Tomcat
internals is tedious and you are likely to lock yourself into a
particular version of Tomcat because the APIs are not necessarily fixed.
If you do it yourself (in my way), you can create a solution that will
work across all versions of all servlet containers and application servers.
Here's the trick: write yourself an HttpSessionListener.
HttpSessionListener (in case you didn't know) receives session "create"
and "destroy" events. All you have to do is implement the
HttpSessionListener interface in a class and then register it as a
<listener> in your web.xml file and it will receive the events.
When a session is created, store the session in a master list that you
maintain (I would recommend a synchronized Map or List). When one is
destroyed, remove it.
Each session will need to know its own IP address, so you'll need to be
recording that information at some point. You could do this with a
Filter, or, if you already have that capability built-into your
application you don't have to worry about it.
Finally, then it's time to run your cleanup, you just traverse all of
the recorded sessions looking at "old" ones
(session.getLastAccessedTime) for a particular IP address
(session.getAttribute("ip.address.that.we.put.in.there.before")). Feel
free to call "invalidate" on any of them.
You can even combine the HttpSessionListener into the object that does
the session harvesting. If I were doing this, I'd write a class like this:
public class MySessionManager
implements HttpSessionListener
{
public void removeOldSessions(String sessionId);
// HttpSessionListener event handlers:
public void sessionCreated(HttpSessionEvent ev);
public void sessionDestroyed(HttpSessionEvent ev);
}
You won't be able to access the "removeOldSessions" method on the
correct object unless you can get to it from somewhere else. I would
recommend coding the sessionCreated() method to check the ServletContext
(application scope) for a copy of itself (say, under the
"MySessionManager" key), and install itself if it's not there.
Then, anywhere in your application that has access to the ServletContext
has access to the running MySessionManager object and can call the
removeOldSessions method.
Note that if there is no MySessionManager object in the ServletContext,
there will be no need to remove sessions (because none have been
created). Therefore, it's safe to do this lazy-style insertion of
MySessionManager into the application scope.
Hope that helps,
- -chris
-- --BEGIN PGP SIGNATURE-- --
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKg0u9CaO5/Lv0PARAipMAJ0UddEZRyUt7UYRDQbAOghk+AQccACguJ8d
vXCyUEY8/BJaTWeIbwKYiCE=
=imyb
-- --END PGP SIGNATURE-- --
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
