httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: pipelined HTTP/1.1 request
Date Sat, 20 Jan 2001 04:53:29 GMT

> another bug is that the close(9) of the /index.html.en file is delayed
> until the end of the connection rather than the end of the request.
> this is a resource leak... i bet it's just registered into the wrong pool.
> it should be on the request pool, not the connection pool.  (or maybe
> we're just lacking a request cleanup?  it happens even when un-pipelined)

Actually, this was done on purpose, and we need to find another way to do
this.  The basic issue is that it is possible for the file to not be sent
before the request pool is cleaned.  This problem can be easily seen by
just requesting the "It Works" page from a standard 2.0 build, after
changing the pool back to the request_rec.  You will get no data at all.

The reason this happens is that we wait for 9K of data before sending out
a request, but if this is the first request in a pipeline, and we have
under 9K, we won't send any data until either we get 9K of data, or there
are no more requests.  Well, we do our best to use sendfile for files, so
we put the file bucket on the brigade in the core_output_filter, but the
file itself was allocated out of the request pool, so when the request
goes away, so does the file, even if it hasn't been sent yet.  That is
VERY bad.

There are a couple of possible solutions:

1)  If we have a file in the brigade, just call sendfile, whether we have
enough for a full packet or not.  Of course, this will need to be more
general, so it will be anything allocated out of a pool other than a pool

I dislike this, because it is a special case and it will usually be wrong.

2)  During the check for the pipelined request, if there is data allocated
out of a pool, send it then.

This is better, but it is still a special case.

3)  Keep things in the connection pool.

This is annoying, because it is a resource leak.

4)  Register a cleanup with the request pool.  This cleanup will basically
take the file bucket and convert it to a malloc bucket.

I kind of like this.  I just thought of it, but it shouldn't be THAT hard
to do.  The idea is simple enough.  If we have a file bucket in the
core_output, we know it is less than 9K, so we are pretty safe to just
read that into memory.  This will also allow us to move the file (and thus
MMAP) back into the request pool.

In case you can't tell, I like option 4 best.  :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message