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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
