On Thu, 2002-12-19 at 10:02, Justin Erenkrantz wrote: > --On Thursday, December 19, 2002 9:45 AM -0800 Brian Pane > <[EMAIL PROTECTED]> wrote: > > > No, we definitely need to do that cleanup in core_output_filter, > > because that's the only code that's guaranteed to still be runnable > > by the time we detect the aborted connection. The handler may have > > finished running long before the connection is aborted, and in an > > async MPM the thread that ran all the other request hooks is likely > > to have moved on to a new request. > > If you abort the connection and core_output_filter doesn't get > called, the request/connection pool seems that it would be leaked. > That's badness.
Right, but there's not a scenario where the core_output_filter doesn't get called. Keep in mind that it's the thing that will have to close the connection in async MPMs, so it has to run on every connection-close. > Yes, if we're sitting in core_output_filter and just trying to shove > data out (we've seen EOS and have all data ready), your solution > works. Yet, I'm concerned about requests that are aborted before EOS > and never make it to core_output_filter. Their pool needs to be > cleaned up somehow. How do you plan on addressing this? The last step in ap_process_request becomes: create the metadata bucket and push it onto the output filter stack. Brian
