tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: ClientAbortException / Broken Pipe?!
Date Wed, 15 Aug 2007 08:59:14 GMT
Kristian Rink wrote:
> Ronald;
> [Ronald Klop <> @ 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 

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

> (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.



To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message