You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nathan Schrenk <ns...@neog.com> on 1996/01/03 03:00:17 UTC

The Apache timeout code is still braindead?

Hi folks,

I recall a short discussion a while back on this list about the Apache 
timeout code being braindead.  What I got out of the discussion (and what 
my short foray into the timeout code seems to verify) is that Apache sets a 
timer when it begins to send out data, and that this timer is never 
adjusted to reflect whether or not data is actively being sent out.

It seems that the correct way to do this is to timeout only after a 
period of inactivity equal to the Timeout value, not to timeout after 
Timeout seconds no matter what.  Has anyone looked into doing this 
correctly?  I ran into a problem where one of my clients has some large 
QuickTime movies on his WWW site, and the 400 second timeout prevented 
people with slower connections from retrieving his movies.  I was 
required to knock the Timeout value up to 1800 (!) seconds so that 14.4K 
modems users would have time to download these files.

This timeout glitchs seems to me to be a major shortcoming in Apache.  In 
my glimpse through the code, it seems that perhaps send_fd() could be 
modified to reset the timeout counter?  In that function perhaps 

--
while ((n= fread(buf, sizeof(char), IOBUFSIZE, f)) < 1
               && ferror(f) && errno == EINTR)
            continue;
--

Could be changed to something like

--
while ((n= fread(buf, sizeof(char), IOBUFSIZE, f)) < 1
        && ferror(f) && errno == EINTR) {
    alarm(0);
    signal(SIGALRM,(void (*)())timeout);
    continue;
  }
--

This is just the first thing that came to me, but it seems like it might 
do the trick.  Any thoughts?

Nathan

--
Nathan Schrenk						nschrenk@neog.com
Neoglyphics Media Corp.                              http://www.neog.com/


Re: The Apache timeout code is still braindead? - OOPS

Posted by Cliff Skolnick <cl...@organic.com>.
I thought there was another alarm pending here, and the use of
alarm() would mess that one up.  Perhaps apache should use non-blocking I/O
to the socket?

Cliff

On Tue, 2 Jan 1996, Nathan Schrenk wrote:

> 
> Oops...  it looks like I cut the wrong loop out of send_fd()...
> What I really meant was:
> 
> This loop
> 
> --
> while(n && !r->connection->aborted) {
>             w=fwrite(&buf[o],sizeof(char),n,c->client);
>             n-=w;
>             o+=w;
> }
> --
> 
> Could perhaps be changed to this loop:
> 
> --
> while(n && !r->connection->aborted) {
>             w=fwrite(&buf[o],sizeof(char),n,c->client);
>             n-=w;
>             o+=w;
>             if (n) {
>                 alarm(0);
>                 signal(SIGALRM,(void (*)())timeout);
>             }
> }
> --
> 
> So now what's wrong with it?  (Other than the fact that it adds the 
> overhead of a comparison and two function calls in this loop).  Will this 
> fix the timeout problem?  What problems does it introduce?  Like I 
> mentioned in my last post, I haven't looked into this very deeply.
> 
> Nathan
> 
> --
> Nathan Schrenk						nschrenk@neog.com
> Neoglyphics Media Corp.                              http://www.neog.com/
> 
> 

Re: The Apache timeout code is still braindead? - OOPS

Posted by Nathan Schrenk <ns...@neog.com>.
Oops...  it looks like I cut the wrong loop out of send_fd()...
What I really meant was:

This loop

--
while(n && !r->connection->aborted) {
            w=fwrite(&buf[o],sizeof(char),n,c->client);
            n-=w;
            o+=w;
}
--

Could perhaps be changed to this loop:

--
while(n && !r->connection->aborted) {
            w=fwrite(&buf[o],sizeof(char),n,c->client);
            n-=w;
            o+=w;
            if (n) {
                alarm(0);
                signal(SIGALRM,(void (*)())timeout);
            }
}
--

So now what's wrong with it?  (Other than the fact that it adds the 
overhead of a comparison and two function calls in this loop).  Will this 
fix the timeout problem?  What problems does it introduce?  Like I 
mentioned in my last post, I haven't looked into this very deeply.

Nathan

--
Nathan Schrenk						nschrenk@neog.com
Neoglyphics Media Corp.                              http://www.neog.com/