On 16 Nov 2010, at 8:56 AM, Ruediger Pluem wrote:
Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1035504&r1=1035503&r2=1035504&view=diff
=
=
=
=
=
=
=
=
=
=====================================================================
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Tue Nov 16
00:23:37 2010
@@ -2643,19 +2643,17 @@ PROXY_DECLARE(int) ap_proxy_connection_c
apr_sockaddr_t *backend_addr = conn->addr;
int rc;
apr_interval_time_t current_timeout;
- apr_bucket_alloc_t *bucket_alloc;
if (conn->connection) {
return OK;
}
- bucket_alloc = apr_bucket_alloc_create(conn->scpool);
/*
* The socket is now open, create a new backend server connection
*/
conn->connection = ap_run_create_connection(conn->scpool, s,
conn->sock,
0, NULL,
- bucket_alloc);
+ c->bucket_alloc);
-1 Veto. This does not work.
Just to clear up any possible perception of otherwise, I have spent
hours and hours trying to pick apart this code and try to understand
exactly what both mod_proxy and mod_ssl are doing, and why
mod_proxy_http is behaving so dramatically differently to
mod_proxy_ftp and mod_proxy_connect, in order to fix a very real
problem in a very real set of datacentres. I would appreciate it if
you could help me get to the bottom of any issues I may not be
understanding so that this can be fixed once and for all. You don't
need to veto anything to get my attention, you can just say "this
won't work and this is why". :)
The socket bucket of the backend connection is created from
this bucket allocator. Hence the reuse of connections from the
backend will be broken
as c->bucket_alloc will be gone when the backend connection and
hence the socket bucket
is reused.
Ok, I originally understood that the conn_rec was recreated each time,
but this isn't the case.
This is making more sense.
What it seems we need to do is keep wrapping buckets in transient
buckets as we were doing before, and then, for the final EOS case,
force the setaside to guarantee that that last set of buckets have
been physically moved to the frontend connection, and the backend can
be safely released and reused.
Regards,
Graham
--
