Bug 41923 - Tomcat doesnt recognized client abort
Summary: Tomcat doesnt recognized client abort
Alias: None
Product: Tomcat Connectors
Classification: Unclassified
Component: Common (show other bugs)
Version: unspecified
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2007-03-21 13:26 UTC by Thomas Jerichow
Modified: 2011-05-21 10:02 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Jerichow 2007-03-21 13:26:28 UTC

i'm using an apache WS with mod_jk 1.2.20 and a tomcat 5.5.xx on a linux 
system. I configured a loadbalancer with a worker. On this worker i 
set "recovery_options=4". I try to catch in my application the client abort ( 
the client close of http connection), but cant get it. In my application i 
cant recognize the close of http connection on client side. Tomcat is writing 
every time succesfully the response, if the client connection is alive or not. 
The status of the response is in every case without an error (error=false) and 
it's commited.
The recovery_option 4, should be used to inform servlet engine about a broken 
client connection but it doesnt work. I tried additionally the JKoption 
DiableReuse, but it doesnt change the situation.

Hope you can help or fix it or you have a workaround for this problem.

thanks a lot for your help

greeting thomsen
Comment 1 Mark Thomas 2007-03-21 19:26:22 UTC
This question would be better asked on the users mailing list.
Comment 2 Thomas Jerichow 2007-03-22 00:20:22 UTC
In my opinion its a bug, cause the description of recovery_option=4 said that 
servlet engine should be informed when client connection is lost. but it 
doesnt works.
Comment 3 Tim Whittington 2007-03-22 15:48:19 UTC
It's worth noting that recovery_options=4 doesn't actually do anything (unless a
fix sneaked in without me noticing) - e.g. the behaviour of option 4 is the
default behaviour.

Comment 4 Thomas Jerichow 2007-03-28 11:38:21 UTC
But did you think its a bug? The documtation suggests here another behaviour. 
Dont know if anybody from the developer team cares about it.
Do you have a workaround for this problem, without changing architecture? I 
looked in mod_jk sources but it contains only handling the response code, if 
recovery_options=4 is set.
Comment 5 Rainer Jung 2008-01-01 18:21:46 UTC
recovery_options 4 was supposed to ensure closure of the Tomcat-JK connection
after client error. In fact this is automatically true, and recovery_options 4
has no effect.

Nevertheless we should investigate, whether a servlet should be able to detect
the connection abort.
Comment 6 Tim Whittington 2011-05-21 10:02:33 UTC
recovery_options 4 has for a long time explicitly flagged the AJP connection to be closed, although that's also the case for all other errors during a request/response cycle. 

The closing of the socket was of the form of a clean shutdown though, with the response stream from Tomcat -> mod_jk being drained while the socket was shut down. This meant that Tomcat never experienced a write error, even when the client aborted the connection to the proxying web server.

In general, this is a limitation of the AJP protocol (there is no mod_jk -> Tomcat communication during the writing of a response, and so no way to feed back errors).

I've made changes to hard close the AJP socket (without draining the response first) when recovery_options 4 is specified. This should propagate the write error back to the Tomcat side in most cases, but at the cost of a socket being left in TIME_WAIT each time.

Without recovery_options 4 specified, the AJP socket will be cleanly shutdown - although the fixes to bug 50839 will mean the AJP socket will still be uncleanly closed if the response exceeds 32k.

I wouldn't rely on catching client aborts on the Tomcat side for anything meaningful (even leaving aside the difficulty in distinguishing a client abort from any other IOException in the Java API), but at least the behaviour matches the documentation to some degree now. Anything more advanced would require an enhancement to the AJP protocol.

This change will be in 1.2.32.