https://issues.apache.org/bugzilla/show_bug.cgi?id=41923
Tim Whittington <t...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Tim Whittington <t...@apache.org> 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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
