httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: proxy_ajp connect timeout fix.
Date Wed, 15 Oct 2008 00:54:38 GMT


On 10/15/2008 02:28 AM, Ruediger Pluem wrote:
> 
> On 10/09/2008 10:11 PM, Matt Stevenson wrote:
>> Had a bit more time, here is a patch that should work for Unix which have "apr_wait_for_io_or_timeout"
available. I can't test windows/others so that's the reason for the ifdef.
>>
>> ProxyPass / balance://hotcluster/
>> <Proxy balance://hotcluster>
>>   # defaultish tomcat
>>   BalancerMember ajp://10.136.130.111:7009  loadfactor=1 connectiontimeout=2
>>   # below IP is not reachable, acts like a down box
>>   BalancerMember ajp://192.168.0.7:7010  loadfactor=1 connectiontimeout=2
>> </Proxy>
>>
>>
>> Index: modules/proxy/proxy_util.c
>> ===================================================================
>> --- modules/proxy/proxy_util.c  (revision 703219)
>> +++ modules/proxy/proxy_util.c  (working copy)
>> @@ -2358,9 +2358,18 @@
>>                       "proxy: %s: fam %d socket created to connect to %s",
>>                       proxy_function, backend_addr->family, worker->hostname);
>>
>> +        /* use non blocking for connect timeouts to work. The ifdef
>> +           limits to unix systems which have apr_wait_for_io_or_timeout.
>> +           TODO: remove the ifdef and see what works/breaks */
>> +#ifdef USE_WAIT_FOR_IO
>> +        apr_socket_opt_set(newsock,  APR_SO_NONBLOCK, 1);
>> +#endif
>>          /* make the connection out of the socket */
>>          rv = apr_socket_connect(newsock, backend_addr);
>>
>> +#ifdef USE_WAIT_FOR_IO
>> +        apr_socket_opt_set(newsock,  APR_SO_NONBLOCK, 0);
>> +#endif
>>          /* if an error occurred, loop round and try again */
>>          if (rv != APR_SUCCESS) {
>>              apr_socket_close(newsock);
>>
> 
> Have you really checked that this patch solves your problem and that the problem
> is not solved without?
> While reviewing this patch for backport I noticed that it is wrong and that it shouldn't
> be needed. The call to apr_socket_timeout_set before apr_socket_connect already sets
the
> socket to non-blocking mode because the timeout of the socket is -1 after creation. A
further
> call to apr_socket_timeout_set (after the connect call does not do this, because the
old
> and the new timeout are >=0). The further code expects the socket to be in non-blocking
> mode, otherwise we have regressions with ssl. This can be notified by running t/ssl/proxy
> on 2.2.x which runs much much slower with the patch applied. This does not happen
> on trunk because the socket is set back to non blocking by the core output filter
> (async write completion).
> So r703998 should be reverted on trunk.

I checked 2.2.x and trunk in the meantime and they behaves as they should *without* the patch.
If I try to connect to a non existing host the apr_socket_connect call returns
after the timeout set via connectiontimeout.
I guess this leaves us to the question whether we need to be able to set
connectiontimeouts below one second.
I reverted r703998 on trunk.

Regards

RĂ¼diger




Mime
View raw message