POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

I commited the fixes for the POST recovery in JK and JK2
when in LB mode which should solve this major problem.

Thanks to take a look at it

Could Alexander who is the original reporter validate the fix ?


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

Re: JK2 release delayed one week ? WAS: POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

Henri Gomez wrote:

> Did you see my request for release delay ?
> 
> The POST patch is important, and I'd like to see it in jk2 2.0.4, I 
> think I may delay the release for one week if others tomcat-dev agreed.
> 
> I wan't to make the behaviour configurable, ie abort or/not if Tomcat
> failed during sending the reply and if Tomcat get the request but didn't
> send the reply, configuration should be at worker level since the
> admins/devels know about the remote side application level.
> 
> Gleen, Jf, Mladen, Kurt, are you agree to delay the jk2 release for one
> week, time for us to include these code in both jk and jk2 and make it
> configurable ?
> 
> Vote please

Nobody object ?

Great, I'll delay the jk 2.0.4 release to next week, time for me to
add the POST recovery configurable schema and for US to fix some of
the still open bugzilla reports.

Gentlemens, IIS, JNI, modules dependances and others are waiting for us.


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

Re: JK2 release delayed one week ? WAS: POST recovery in JK and JK2 HEAD

[Kurt Miller <tr...@apache.org>]

From: "Henri Gomez" <hg...@apache.org>
> Did you see my request for release delay ?
>
> The POST patch is important, and I'd like to see it in jk2 2.0.4, I
> think I may delay the release for one week if others tomcat-dev
agreed.
>
> I wan't to make the behaviour configurable, ie abort or/not if
Tomcat
> failed during sending the reply and if Tomcat get the request but
didn't
> send the reply, configuration should be at worker level since the
> admins/devels know about the remote side application level.
>
> Gleen, Jf, Mladen, Kurt, are you agree to delay the jk2 release for
one
> week, time for us to include these code in both jk and jk2 and make
it
> configurable ?
>
> Vote please
>

+0

I'm ok with the delay but I don't have time this week to help.

-Kurt


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

JK2 release delayed one week ? WAS: POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

Did you see my request for release delay ?

The POST patch is important, and I'd like to see it in jk2 2.0.4, I 
think I may delay the release for one week if others tomcat-dev agreed.

I wan't to make the behaviour configurable, ie abort or/not if Tomcat
failed during sending the reply and if Tomcat get the request but didn't
send the reply, configuration should be at worker level since the
admins/devels know about the remote side application level.

Gleen, Jf, Mladen, Kurt, are you agree to delay the jk2 release for one
week, time for us to include these code in both jk and jk2 and make it
configurable ?

Vote please

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

Re: POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

Alexander Schwartz wrote:
>>>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
> sent.
> 
> The following considerations have been made:
> 
>    * after data has been sent to the client don't try to recover
>      from a tomcat has failure

Seems the correct behaviour.

>    * 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?)

Good.

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

If no headers has been returned by Tomcat ? Interesting point since
we couldn't be sure he get the request.

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

This patch is important, and I'd like to see it in jk2 2.0.4, I think I 
may delay the release for one week if others tomcat-dev agreed.

I wan't to make the behaviour configurable, ie abort or/not if Tomcat
failed during sending the reply and if Tomcat get the request but didn't
send the reply, configuration should be at worker level since the 
admins/devels know about the remote side application level.

Gleen, Jf, Mladen, Kurt, are you agree to delay the jk2 release for one
week, time for us to include these code in both jk and jk2 and make it
configurable ?

Vote please


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

Re: POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

Ok, I make the code configurable with a worker option,
recovery_options.

By default we keep the current behaviour, ie allways recover.

Set recovery_options (bitfield) to 1 to make reovery stopped if
tomcat get all request and to 2 to make recovery stopped if tomcat
send the headers to clients.

To have both set recovery_options to 3..

Thanks to test and validate before I see how to port this to jk2



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

Re: POST recovery in JK and JK2 HEAD

[Alexander Schwartz <al...@gmx.net>]

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

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.

Alex.

-- 
Alexander Schwartz (alexander.schwartz@gmx.net)
http://www.ahus1.de

Re: POST recovery in JK and JK2 HEAD

[Henri Gomez <hg...@apache.org>]

Alexander Schwartz wrote:

>>I commited the fixes for the POST recovery in JK and JK2
>>when in LB mode which should solve this major problem.
>>
>>Could Alexander who is the original reporter validate the fix ?
> 
> 
> YES and NO:
> 
> Post recovery works now in the scenario, the loadbalancer doesn't forget
> the post body when a tomcat fails. 
> 
> 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),
> but you have already been discussing this under the subject "Mod_Jk2 -
> Default Worker".
> 
> 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.


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

Re: POST recovery in JK and JK2 HEAD

[Alexander Schwartz <al...@gmx.net>]

> I commited the fixes for the POST recovery in JK and JK2
> when in LB mode which should solve this major problem.
>
> Could Alexander who is the original reporter validate the fix ?

YES and NO:

Post recovery works now in the scenario, the loadbalancer doesn't forget
the post body when a tomcat fails. 

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),
but you have already been discussing this under the subject "Mod_Jk2 -
Default Worker".

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

Alex.

-- 
Alexander Schwartz (alexander.schwartz@gmx.net)
http://www.ahus1.de


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