With the following patch from trunk you are able to set retry to 0, which should fix your actual problem:
Thanks!
But I think in general it is not advisable to do this at least if you are load balancing your backend / having a failover configuration. And even if you do not have such a configuration from my perspectivce it looks like to be important to find out why you get these connection timeouts. So what protocol do you speak with your backend? HTTP? What are the error messages you see in the error log?
BTW, I did test my patch when 1 host was down in a balancer configuration. It still seemed to work well. I agree that there is a trade off for this. If the remote system is really slow or hung, connections can build up and overload Apache (e.g. you run out of worker threads, run out of file descriptors, etc). As soon as we fix the network problem, we'll probably want to use a higher retry value. At this time, we lose one or two connections out of thousands. According to the network sniffer for these connections, packets are getting lost during the setup of the connection. (For example - our sniffer sees a SYN go out, get retransmitted a couple times, but the SYN_ACK never returns for that one connection). It could have something todo with the HW load balancer, the NAT firewall between us and the destination, remote web servers, or something else. We're still working on the analysis. As requested, here is the error: [Tue May 01 14:36:30 2007] [error] (145)Connection timed out: proxy: HTTPS: attempt to connect to 1.2.3.4:443 (hostname.com) failed [Tue May 01 14:36:30 2007] [error] ap_proxy_connect_backend disabling worker for (hostname.com) Thanks again for your help! Brian
