Hi Chris,
interesting use case :)
mod_jk closes the backend connection as soon as the reply_timeout fires,
or there is something to write back to the client and mod_jk detects,
that the connection to the client can not be used any longer (browser
stop, retry or click on another link).
If the user ends waiting for the reply and you don't try to write
something back, mod_jk won't detect that, because it sits there and
waits for something to come back from the backend. So to reliably detect
a browser stop, you need to actively use the connection. From you
comments about the mod_jk log file, it seems, that you are actually
doing this.
Why doesn't Tomcat immediately throw the exception: I guess (wild
guess), that it also only notices the closed mod_jk connection, if it
tries to use it. If you are actually using it continuously we would have
to investigate, why there is such a delay.
So first question to get closer would be: are you writing something back
during the wait time, or are you simply doing processing on the backend?
In this case (because I don't understand the client abort detection of
mod_jk then): Can you reproduce the behaviour for a single request on a
test system using JkLogLevel debug?
Please make sure, that the clocks on the mod_jk system and on the Tomcat
system are in sync.
Regards,
Rainer
Chris Hut wrote:
Hi all,
We're using Apache 2.0.61 with mod_jk 1.2.25 and Tomcat 6.0.14.
We have a simple (non-load-balanced) apache/tomcat configuration using a
single worker to forward requests from apache to tomcat.
(workers.properties is below)
Our problem is: Some client requests kick off an expensive, long-running
server-side process. Often, the client will give up (e.g. the user will
navigate to a different browser page) before completion, and we want to
cancel the server-side process early if possible.
We use the ClientAbortException to easily set an "interrupted" flag
which our process monitors to see if it should abort. When connecting
straight to the servlet using Tomcat only, this is very simple as the
exception is thrown immediately and the process dies right away. This
is what we hope for.
When connecting via apache/mod_jk, though, it takes 30 seconds for the
exception to be thrown in Tomcat. For efficientcy we'd love the abort
to happen immediately if possible.
In the mod_jk.log file, we see this as soon as the client aborts (e.g.
closes browser):
[Thu Jan 24 20:09:35.535 2008] [2011:1094711648] [info]
ajp_process_callback::jk_ajp_common.c (1511): Writing to client aborted
or client network problems
[Thu Jan 24 20:09:35.535 2008] [2011:1094711648] [info]
ajp_service::jk_ajp_common.c (1996): (worker1) request failed, because
of client write error without recovery in send loop attempt=0
But it takes 30 seconds to see:
[Thu Jan 24 20:10:05.641 2008] [2011:1094711648] [info]
jk_handler::mod_jk.c (2270): Aborting connection for worker=worker1
Which corresponds exactly to the time when the ClientAbortException is
thrown in Tomcat.
Given the exact nature of the timing involved (30 seconds) I'm
guessing/hoping this is an apache and/or JK timeout setting; however, I
can't find a property that would do what we require which is just to
kill the Tomcat connection faster if the end-user client closes the
connection on their side.
Can anybody point me to a setting to tweak? I did try using
recovery_options=4 (which says, "close the connection to Tomcat, if we
detect an error when writing back the answer to the client (browser)")
but the behavior is unchanged. I feel like changing the worker timeouts
is the wrong direction because the JK-to-Tomcat communication is working
just fine, we just need a way to propagate JK's client-abort error to
Tomcat faster!
Thanks for your help!
workers.properties:
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
#worker.worker1.retries=4
Chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
