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
