httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Proxy regressions
Date Wed, 10 Nov 2010 10:46:44 GMT
On 10 Nov 2010, at 11:49 AM, Plüm, Rüdiger, VF-Group wrote:

>> Have we not created a pool lifetime problem for ourselves here?
>>
>> In theory, any attempt to read from the backend connection should
>> create buckets allocated from the r->connection->bucket_alloc
>> allocator, which should be removed from the backend connection when
>> the backend connection is returned to the pool.
>
> I guess we need a dedicated bucket_allocator at least in the beginning
> as we cannot guarantee that anyone in the create_connection hook uses
> the bucket_allocator to create an object that should persist until the
> connrec of the backend connection dies.
>
> Exchanging the allocator later each time we get the connection from
> the conn pool might create similar risks. But I admit that the later
> is only a gut feeling and I simply do not feel well with exchanging  
> the
> allocator. I have no real hard facts why this cannot be done.

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.

> So without trying to offend anyone, can we see the use case for the  
> asap returning
> again?

Right now, we are holding backend connections open for as long as it  
takes for a frontend connection to acknowledge the request. A typical  
backend could be finished within milliseconds, while the connection to  
the frontend often takes hundreds, sometimes thousands of  
milliseconds. While the backend connection is being held open, that  
slot cannot be used by anyone else.

In addition, when backend keepalives are kept short (as ours are), the  
time it takes to serve a frontend request can exceed the keepalive  
timeout, creating unnecessary errors.

This issue is a regression that was introduced in httpd v2.2, httpd  
2.0 released the connection as soon as it was done.

Regards,
Graham
--


Mime
View raw message