httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS
Date Fri, 07 Nov 2008 16:33:18 GMT
On Fri, Nov 07, 2008 at 01:29:15PM +0100, "Plüm, Rüdiger, VF-Group" wrote:
> > Would it be possible to substitute the backend ("fake") conn_rec's 
> > ->bucket_alloc pointer with the "real" r->connection->bucket_alloc, 
> > for the duration of the request/response to the backend?  Wouldn't 
> > that ensure that all the buckets in question exactly have the 
> > correct lifetime?
> I though about this as well, but I suppose this is a risky road to take.
> Keep in mind that mod_ssl and the core network filters below might use this
> bucket allocator and that we keep this backend connection alive while the front
> end connection might have died. So we might still have buckets in this
> backend connection pipe created by the previous request that are dead on the
> new request. This may cause segfaults when we start using the backend
> connection again.

Fair enough.  Transmuting the buckets into TRANSIENTs seems like a 
reasonable solution, in any case, it's sort of saying "lifetime issues, 
buyer beware" in bucket-speak which exactly matches the problem in hand.

In ap_proxy_buckets_lifetime_transform() is there any reason to restrict 

+            || APR_BUCKET_IS_IMMORTAL(e) || APR_BUCKET_IS_POOL(e)) {
+            apr_bucket_read(e, &data, &bytes, APR_BLOCK_READ);

instead of simply:

         if (!APR_BUCKET_IS_METADATA(e)) {
            // ...likewise transmute to a TRANSIENT

?  You already know that the brigade size is constrained, right, so 
there is no worry about memory consumption from morphing buckets, and 
the technique should should work equally well for any data bucket?

Apologies if you've already thought about this too but it might be worth 
a comment in the code explaining why, if so :)

Regards, Joe

View raw message