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

Reply via email to