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