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
--
