httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <>
Subject Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS
Date Fri, 07 Nov 2008 12:29:15 GMT

> -----Ursprüngliche Nachricht-----
> Von: Joe Orton [] 
> Gesendet: Freitag, 7. November 2008 13:11
> An:
> Betreff: Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS
> 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?

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.



View raw message