httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS
Date Fri, 07 Nov 2008 12:10:54 GMT
On Thu, Nov 06, 2008 at 09:58:52PM +0100, Ruediger Pluem wrote:
> What is the problem at all?
> 
> mod_proxy_http uses a a conn_rec to communicate with the backend. It somehow reverses
> the meaning of input and output filters and uses them to send the request and receive
> the response. In order to use persistent SSL connections to the backend it is needed
> to keep this conn_rec (and thus its bucket allocator) alive and tied to the backend
> connection. Thus it is no longer destroyed at the end of a client request / connection.
> So the conn_rec and especially the bucket allocator for the backend have a lifecycle
> that is disjoint from the one to the client. Especially it can happen that due to e.g.
> a faulty backend connection the conn_rec to the backend *lives* shorter than
> buckets that are still buffered somewhere in the output filter chain to the client
> (see comments in removed code below). This causes segfaults when these buckets are
> accessed then or if brigades that contain them get cleaned up later on due to a parent
> pool cleanup.

Not sure if I've got my head round this correctly, but...

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?

Regards, Joe

Mime
View raw message