httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <>
Subject Re: [PATCH]: Counting of I/O, complete thingy
Date Mon, 14 Oct 2002 23:43:03 GMT
On Tue, 2002-10-15 at 00:41, William A. Rowe, Jr. wrote:

> I'm not sure, did you note that the core_output_filter will still be running after
> the request rec is gone?  That is, the pool will be emptied as the tail of the
> request has still not been sent to the client.  This is most true in pipelined
> requests.

I'm not 100% sure I understand which pool use you are referring to in
this case. The only pool use is in mod_logio, functions log_bytes_in and
log_bytes_out (this hasn't changed from the currently commited
mod_logio). I guess the request should be very much alive at that point.
Otherwise, how does normal logging in mod_log_config (which calls those
functions) work in the first place?

>   Is this really the complete solution?  I suspect the three-pool approach
> might solve all these problems;
> Connection [lifetime of the socket]
>   Response [everything but the handler lives here, 
>                  until the entire Response is flushed]
>     Request [this pool lives until the response is generated, then dumped.]
> This way, the logging phase has everything constructed in the Response
> pool, and it can outlive the handler so that real information can be logged.

I can't really comment on this new approach, simply because I don't know
enough about the whole architecture. As for the patch itself, I'm not
sure that it is a complete solution, but I tried to identify (probably
quite naively) all the places that actually write data to the network. I
might have missed a spot somewhere...

This is what I tested with:

- plain files
- Velocity pages in Tomcat 3.3.1 with mod_jk 1.2.0
- PHP 4.2.3

They all seem to be OK. 


PS. I used the V2 of the patch for some of these test, but the pool
logic hasn't changed much between the two, so I don't see how we'd have
memory allocation issues.

View raw message