The JK docs state:
"If the value 4 is added to the recovery options, the connection between the
webserver and tomcat will be closed if the client connection to the webserver
is terminated during the request/response cycle. This allows to inform the
servlet engine about broken client connections during lengthy operations."
This seems to imply that recovery_options=0 will reuse the connection if the
only errors were client read/writes, which is not the case.
The connection between the webserver and Tomcat is always closed on an error
writing to a client though, and I'm fairly certain if there are client read
errors.
Since the only place that socket reuse is set to true is in the AJP end
response, which is always after the client reads and writes are done in
ajp_send_request or ajp_get_reply, and the end_response is never reached if
there is a read/write error, there is no recovery of AJP connections.
It appears that recovery_options=4 is redundant - am I missing something?
If the AJP protocol handlers were coded to reset the protocol stream on one of
these errors to allow it to be reused, then this flag would come into play and
would work as documented.
tim