> -----Original Message----- > From: "Plüm, Rüdiger, VF-Group" > Sent: Mittwoch, 10. November 2010 14:55 > To: dev@httpd.apache.org > Subject: RE: Proxy regressions > > > > > -----Original Message----- > > From: Graham Leggett > > Sent: Mittwoch, 10. November 2010 14:05 > > To: dev@httpd.apache.org > > Subject: Re: Proxy regressions > > > > On 10 Nov 2010, at 1:09 PM, Plüm, Rüdiger, VF-Group wrote: > > > > >> The proxy currently creates the allocator in > > >> ap_proxy_connection_create(), and then passes the > allocator to the > > >> various submodules via the ap_run_create_connection() hook, so it > > >> looks like we just passing the wrong allocator. > > > > > > The problem is that we keep the connrec structure in the > conn pool. > > > It is not created each time we fetch a connection from the > > conn pool. > > > This is required to enable keepalives with SSL backends. > > > As said if we pass the bucket allocator from the front end > > connection > > > we possibly end up with other pool lifetime issues and as > I speak of > > > it SSL comes to my mind. > > > > This doesn't sound right to me - ideally anything doing a read of > > anything that will ultimately be sent up the filter stack > should use > > the allocator belonging to the frontend connection. When > the backend > > connection is returned to the pool, the allocator should be > removed, > > and the next allocator inserted when the backend connection is > > subsequently reused. > > > > Currently what we seem to have is data allocated out of a > pool that > > has a lifetime completely unrelated to the frontend request, > > and then > > we're working around this by trying to keep this unrelated > > pool alive > > way longer than it's useful lifetime, and at least as long as the > > original request. This seems broken to me, we should really > be using > > the correct pools all the way through. > > As said this sounds doable for http backends, but not for > https backends > where we need to keep some data regarding the SSL state in > the conn rec > of the backend connection.
The core input filter in ap_core_input_filter which is used to read the response from the backend creates the socket bucket from the conn rec bucket allocator. So the used bucket allocator must live as long as the conn rec of the backend connection lives. And the conn rec of the backend connection lives longer then one request and possibly longer than the frontend connection if the backend has keepalive enabled, in fact it is reused by the next frontend request that leases the backend connection from the backend connection pool. Regards Rüdiger
