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