You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kai Risku <kr...@arrak.fi> on 2002/10/20 22:42:01 UTC
[PATCH] Fix for bug #7617: race condition causes 3 second CGI delay
When running my newly installed apache 2.0.40 on my RedHat
8.0 linux box, I noticed some strange 3-second delays
for clients using keepalives after running CGI scripts
before the next request was processed.
Some debugging led me to the conclusion that I experienced
the same race-condition as described as #7616 in the bug
database. I.e. after running the CGI script, apache finds
the subprocess to still be active, sends it a SIGINT and
then blocks for three whole seconds before sending a SIGKILL.
Meanwhile, the client using keep-alives is kept waiting
for those three seconds until the next request is processed.
What a waste of time, considering the CGI script actually
exited almost immediately after the SIGINT was sent.
I confirmed this same behaviour to be present in version 2.0.43,
and saw the need to make a fix to this. Apache 1.3.27 has
very similar code, so the same patch could be easily modified
to work with that version as well!
Please find enclosed a patch against the 2.0.40 source tree
(should work well on 2.0.43 also) that fixes this unnecessary
delay. The patch makes apache check the status of the subprocesses
in 0.1 second intervals, until either a total of three seconds
have elapsed or all subprocesses have exited. Any subprocesses
still running after 3 seconds are then SIGKILLed as before.
Hope this quick fix can make it into the official version!
Best regards,
Kai
--
Kai.Risku@arrak.fi Oy Arrak Software Ab
GSM +358-40-767 8282 http://www.arrak.fi
RE: [PATCH] Fix for bug #7617: race condition causes 3 second CGI delay
Posted by Bill Stoddard <bi...@wstoddard.com>.
Kai,
Thanks for the patch. I will be committing it later this evening.
For future reference APR patches to APR should be posted to dev@apr.apache.org.
Thanks again.
Bill
>
> When running my newly installed apache 2.0.40 on my RedHat
> 8.0 linux box, I noticed some strange 3-second delays
> for clients using keepalives after running CGI scripts
> before the next request was processed.
>
> Some debugging led me to the conclusion that I experienced
> the same race-condition as described as #7616 in the bug
> database. I.e. after running the CGI script, apache finds
> the subprocess to still be active, sends it a SIGINT and
> then blocks for three whole seconds before sending a SIGKILL.
> Meanwhile, the client using keep-alives is kept waiting
> for those three seconds until the next request is processed.
> What a waste of time, considering the CGI script actually
> exited almost immediately after the SIGINT was sent.
>
> I confirmed this same behaviour to be present in version 2.0.43,
> and saw the need to make a fix to this. Apache 1.3.27 has
> very similar code, so the same patch could be easily modified
> to work with that version as well!
>
> Please find enclosed a patch against the 2.0.40 source tree
> (should work well on 2.0.43 also) that fixes this unnecessary
> delay. The patch makes apache check the status of the subprocesses
> in 0.1 second intervals, until either a total of three seconds
> have elapsed or all subprocesses have exited. Any subprocesses
> still running after 3 seconds are then SIGKILLed as before.
>
> Hope this quick fix can make it into the official version!
>
> Best regards,
> Kai
>
> --
> Kai.Risku@arrak.fi Oy Arrak Software Ab
> GSM +358-40-767 8282 http://www.arrak.fi
>
RE: [PATCH] Fix for bug #7617: race condition causes 3 second CGI delay
Posted by Bill Stoddard <bi...@wstoddard.com>.
Kai,
Thanks for the patch. I will be committing it later this evening.
For future reference APR patches to APR should be posted to dev@apr.apache.org.
Thanks again.
Bill
>
> When running my newly installed apache 2.0.40 on my RedHat
> 8.0 linux box, I noticed some strange 3-second delays
> for clients using keepalives after running CGI scripts
> before the next request was processed.
>
> Some debugging led me to the conclusion that I experienced
> the same race-condition as described as #7616 in the bug
> database. I.e. after running the CGI script, apache finds
> the subprocess to still be active, sends it a SIGINT and
> then blocks for three whole seconds before sending a SIGKILL.
> Meanwhile, the client using keep-alives is kept waiting
> for those three seconds until the next request is processed.
> What a waste of time, considering the CGI script actually
> exited almost immediately after the SIGINT was sent.
>
> I confirmed this same behaviour to be present in version 2.0.43,
> and saw the need to make a fix to this. Apache 1.3.27 has
> very similar code, so the same patch could be easily modified
> to work with that version as well!
>
> Please find enclosed a patch against the 2.0.40 source tree
> (should work well on 2.0.43 also) that fixes this unnecessary
> delay. The patch makes apache check the status of the subprocesses
> in 0.1 second intervals, until either a total of three seconds
> have elapsed or all subprocesses have exited. Any subprocesses
> still running after 3 seconds are then SIGKILLed as before.
>
> Hope this quick fix can make it into the official version!
>
> Best regards,
> Kai
>
> --
> Kai.Risku@arrak.fi Oy Arrak Software Ab
> GSM +358-40-767 8282 http://www.arrak.fi
>