tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Limit user sessions in tomcat
Date Tue, 15 Dec 2009 19:41:38 GMT
Chetan Chheda wrote:
> 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
> 
This is typically the case you indicate :

- a user clicks on a link, sending a request to Apache
- Apache passes the request to mod_jk and waits for mod_jk to provide a 
response
- mod_jk forwards the request to Tomcat
- Tomcat receives the request and passes it to a thread for execution
- the thread takes xxx time to process the request and produce the response
- the thread sends the response back to mod_jk, and is now done
- mod_jk wants to send the response back to Apache (and the client), but 
on writing to the client socket, gets an error, namely that the other 
end is no longer there (the client browser has closed the connection, 
because the user clicked somewhere else, maybe several minutes ago)
- mod_jk logs the error above
- but by that time, it is too late to do anything useful about it in 
Tomcat, because the webapp thread has already done all its processing 
for the request (uselessly).

At the Tomcat webapp level, you can either do something like Christopher 
is suggesting (which avoids *accepting* additional identical requests 
from the same client, until this request is processed), or you can try 
to modify the application so that it at least starts returning something 
to the client very early in the request processing cycle.
If it does that, it will get the error which mod_jk is seeing, "bubbled 
up" to its own response socket, much earlier.  That may at least avoid 
unnecessary processing.

Or again, you can try and catch these events much earlier, before they 
even get to Tomcat and start using up Tomcat resources.

Being myself an Apache/mod_perl guy more than a Tomcat/Java guy, I would 
do this by means of a PerlAccessHandler at the Apache front-end level, 
implementing much the same logic as Chris mentions in his post about a 
servlet filter.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message