Kristian Rink wrote:
Ronald;
[Ronald Klop <[EMAIL PROTECTED]> @ Wed, 15 Aug 2007 09:56:59
+0200 (CEST)]
ClientAbortException means the user canceled the download (the
'client aborted'). There is nothing you can do about that on the
server.
I thought so. However, there are two things:
(a) I was unsure whether, in a proxied environment, a
"ClientAbortException" means download canceled by the actual (external)
"client" or by the proxy server (which is directly accessing the
backend tomcat).
OK, the proxy in your case is a reverse proxy. The exception in the
tomcat logs could theretically come from a communication failure back to
the reverse proxy, or from a failure from the reverse proxy back to the
client=browser. In the latter case, the reverse proxy would not accept
any more traffic from the tomcat and thus indirectly lead to the same
exception.
When using mod_jk, it will log problems during sending back data to the
client=browser. That way you would know, on which part of the net the
original problem is located.
By logging response times in your Apache access log and redundantly in
your Tomcat access log (at least until you solved or understood the
cause of the problem), you can also find out, how long the response took
from the perspective of Apache and of Tomcat, and if the duration is
close to some configured timeout interval. The pattern for response
times if "%D", which means microseconds with Apache httpd and
milliseocond swith Tomcat. From the mod_jk log and the access log
duration information you might even be able to determine, which requests
had the problem (this is not easy and if you've got high load, it's
difficult). I would suggest using mod_jk 1.2.25. It will log millisecond
timestamps and has a couple further stability improvements. You wrote
about version 1.2.29 which does not exist, upgrading should be no problem.
JK has a couple of timeouts additionally to the Apache httpd timeout.
They are described at
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
(b) In none of the cases I watched so far, some user consciously /
actively stopped a download in progress - all reported that either the
"download finished" but ended up with an empty / small / corrupted file
or an error message showed up - or nothing happened at all. :(
I am not really sure who's to blame for that... :/
I would really try to look at the response handling times, the URLs for
which it is happening, the client IPs and User Agent types to check, if
there are any obvious patterns.
In case you can finally reproduce the problem with low load, you can
switch jk log level to debug or even trace. Then the log file will
include full packet and header dumps. This is not a good idea for high
traffic production though.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
