httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1035504 - in /httpd/httpd/trunk: include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Date Tue, 16 Nov 2010 09:52:57 GMT
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
--


Mime
View raw message