ASF Bugzilla – Full Text Bug Listing
|Summary:||Tomcat doesnt recognized client abort|
|Product:||Tomcat Connectors||Reporter:||Thomas Jerichow <T.Jerichow>|
|Component:||Common||Assignee:||Tomcat Developers Mailing List <dev>|
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://email@example.com/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.