Bug 41923

Summary:	Tomcat doesnt recognized client abort
Product:	Tomcat Connectors	Reporter:	Thomas Jerichow <T.Jerichow>
Component:	Common	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P2
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	other

Description Thomas Jerichow 2007-03-21 13:26:28 UTC

Hi,

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.

http://www.mail-archive.com/dev@tomcat.apache.org/msg12958.html

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.