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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
