In 2.4's http_request.c there are two places doing:
bb = apr_brigade_create(c->pool, c->bucket_alloc);
to handle sending a FLUSH between requests and an EOR bucket which both
can't be done off r->pool. Because the brigade structure itself is
allocated out of c->pool this means we leak (~64bytes) per request
forever or up to request/conn limits.
We can thread a temp pool through to those functions and fix this,
though because these core internal functions are in the public API (ha
ha) this is the usual compat PITA, and I haven't worked out if that's
more complex for the the async requesta processing call chain.
As a PoC for non-async MPMs:
http://people.apache.org/~jorton/2.4-use-temp-pool.patch
Another choice is to allocate the brigade structure using the bucket
allocator and actually free it on _destroy(). Anybody around who can
remember why we used a pool allocation for that structure from the
beginning?
http://people.apache.org/~jorton/apr-util-brigade-bucket-alloc.patch
plus http://people.apache.org/~jorton/2.4-missing-brigade-destroy.patch
This seems like a simple change but it could have some nasty regressions
if there places where a brigade is reused after calling
apr_brigade_destroy(). Currently that itself can create leaks because
there is no pool cleanup but will otherwise work. I'm also not sure if
there are performance implications.
Also I'd previously written that it was a bad idea to ever call
apr_brigade_destroy() so this is kind of reversing that advice...
https://httpd.apache.org/docs/trunk/developer/output-filters.html#brigade
Whether or not this is a good idea in apr-util 1.x I'm not at all sure.
Any thoughts?
Regards, Joe
