recovery_option 4 not fully implemented

[Tim Whittington <Ti...@orionhealth.com>]

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

Re: recovery_option 4 not fully implemented

[Rainer Jung <ra...@kippdata.de>]

Tim Whittington schrieb:
> 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's a little late in the evening, but I think I agree with you. The
flag reuse is set to false at the beginning of service and is only set
to true during the JK_AJP13_END_RESPONSE callback, but in any case we
get a client read or write error we abort earlier.

Mladen, do you agree?

>  
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org