tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Schwartz <>
Subject Re: POST recovery in JK and JK2 HEAD
Date Mon, 16 Feb 2004 11:57:48 GMT
> > THIS DOES NOT FIX the problem with the output when tomcat already sent
> > data to the client (see my mail date Thu, 12 Feb 2004 23:33:34 +0100),
> >
> > My two cents: when the tomcat fails after data has been sent to the
> > client, assume that the request is complete, i.e. return JK_TRUE
> > (otherwise apache will add some error messages to the reply).
> Ok, if you have fix for jk AND jk2, thanks to provide them quickly so we
> could include in in 2.0.4 and 1.2.6 release.

This is not as easy as I thought: I have extended ajp_get_reply() and
ajp_process_callback() to keep track if the headers have already been

The following considerations have been made:

   * after data has been sent to the client don't try to recover
     from a tomcat has failure

   * if I return JK_FALSE with recoverable = JK_FALSE apache will
     append its standard error page. This might look quite ugly, but
     this way we get proper access.log entries. This might also trigger
     some error handling in apache (closing the socket even if client
     tried keepalive and tomcat sent a content length?)

   * it's up to you to decide if mod_jk should try to recover after
     when no headers have been sent (see tag DISCUSSION in code)

The best thing to do after a tomcat failure (after data has been already
sent to the client) would be to mark it as not recoverable, write a proper
log entry in access.log and to force apache to close this connection
immediately without sending any other data. This should handle any
problems arising from chunked responses and/or content-length headers. But
I don't know how to implement that.

The included patch is only for jk, not jk2.


Alexander Schwartz (

View raw message