Thanks Peter for the clarification. My background is that of a UNIX
administrator not a web administrator and its showing from my posts..
My problem is long running requests. If the requests take longer than their
fancy, the users just close the browser window, open a new one and resubmit the
same request.
I also noticed a lot of the following in my mod_jk logs which to me means the
user killed the browser? ...
[Tue Dec 15 02:56:30.491 2009] [3460:93] [info] jk_ajp_common.c (1688): Writing
to client aborted or client network problems
[Tue Dec 15 02:56:30.492 2009] [3460:93] [info] jk_ajp_common.c (2315): (31)
sending request to tomcat failed (unrecoverable), becau
se of client write error (attempt=1)
[Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1339): service
failed, worker 31 is in error state
[Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1360):
unrecoverable error 200, request failed. Client failed in the
middle of request, we can't recover to another instance.
[Tue Dec 15 02:56:30.778 2009] [3460:93] [info] mod_jk.c (2421): Aborting
connection for worker=loadbalancer
________________________________
From: Peter Crowther <peter.crowt...@melandra.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tue, December 15, 2009 12:42:01 PM
Subject: Re: Limit user sessions in tomcat
2009/12/15 Chetan Chheda <chetan_chh...@yahoo.com>
> Is there a 3rd party tool available to manage tomcat sessions and kill
> them once they go rogue?
>
> Can I just check two pieces of terminology?
In Tomcat (and many other web servers), a "session" is the notion that a
user will make multiple requests to the server from the same browser over
time. It's also used to refer to any data that the application keeps
between these requests from the same user. I'm not aware of a way that a
session could "go rogue" except by getting more and more data stored in it -
in which case, it's time to file a bug report with your external development
house and tell them to fix the leaky code!
A single "request" to the server is one HTTP request from the browser* to
the server, and the response from server to browser. This can cause
problems if it takes a long time to service. Each request uses one thread
while it is being serviced, then that thread is returned to the pool once
the request completes. I'm not aware of any tool that will allow you to
kill threads in the middle of a request if they "go rogue".
Are you having problems with rogue (large) sessions, or with rogue
(long-running) requests?
- Peter
* Yes, to the pedants out there, I know this should more generally be called
a user-agent or even a client, as so many HTTP requests now come from web
services.
