Re: Request for comments: moving the request pool cleanup

[Justin Erenkrantz]

--On Wednesday, December 18, 2002 3:23 PM -0800 Brian Pane <[EMAIL PROTECTED]> wrote:

My proposed changes are:
  - Create each top-level request pool as a free-standing pool,
    rather than a subpool of the connection pool.
  - After generating the response, don't destroy the request pool.
    Instead, create a metadata bucket that points to the request_rec
    and send this bucket through the output filter chain.
  - In the core_output_filter, once everything before this metadata
    bucket is sent, run the logger and then destroy the request
pool.

Obvious question, but what happens if we don't get to that metadata bucket? If we get an error, do we have to go the end of the brigade? What if we get to an abort situation before we see an EOS? When would we clean it up?

Would such a bucket come before or after the EOS bucket? Hmm, if we had a bucket type extension system (something we kicked around at AC), we could create a 'super' EOS bucket which had the pool associated with it.

Good idea, but I'd like to be sure we handle errors right. -- justin