I put the docs guys on CC as there might be (hopefully :-)) someone over there who is interested in cleaning up the documentation mess regarding this.
On 06/16/2007 02:17 AM, Jess Holle wrote: > Ah, that would make sense -- but that's not what the docs say as you > point out :-) > > -- > Jess Holle > > Rainer Jung wrote: > >> I think you need to make a distinction between the timeout *attribute* >> on a BalancerMember and the one on a balancer itself. At least the >> code does the distinction (2.2.4). >> >> a) timeout for a Balancermember (aka worker): timeout waiting for a >> read or write on an existing backend connection to complete. >> >> b) timeout for a balancer: if it can't get a connection from the pool, >> it will try again in intervals of timeout*1000/100 milliseconds until >> timeout seconds have expired (i.e. 100 times) or it managed to get a >> connection, Not the complete story IMHO. The balancer will run over its members as described above (so 100 times, with a sleep of timeout*1000/100 ms in between). But as soon as a member is found that is usable there might be an additional waiting time depending on the settings of this member. If you have configured your member with the acquire parameter it will wait up to acquire seconds for a connection to become available in the pool that is either one is created if the current pool size is smaller than max and all connections in the pool are used or there is a free connection in the pool. If you have not used the acquire parameter, httpd will wait indefinitely for a connection to become available. Of course this waiting period (limited / unlimited) can only happen if 1. The value for max is set to a value lower than ThreadsPerChild. 2. Possibly if the value for max is unset or set to ThreadsPerChild with the event MPM. 3. We have a connection pool leak :-). >> >> I think the documentation does not correctly document the code for the >> a) part! Yes, the documentation definitely needs some improvement. >> >> Regards, >> >> Rainer >> >> >> Jess Holle wrote: >> >>> Okay, I'm still wondering about the future behavior based on the "Re: >>> ProxyTimeout does not work as documented" thread (which is why I'm >>> bothering the dev mailing list, since the thread is from there), but >>> after some testing the current (2.2.4) behavior is clearly that: >>> >>> 1. If no timeout is specified on proxy workers: >>> * They will wait indefinitely for a free connection to the >>> back end. No, but see my explanations above regarding acquire. >>> * They will wait for ProxyTimeout or 300 seconds for a >>> response from the back end servers. No. They will wait for the timeout set by the Timeout setting for this virtual server. But this is wrong. It should be worker timeout / ProxyTimeout / Timeout in that order with only having Timeout a default of 300 secs if not set. >>> 2. If a timeout is specified on proxy workers: >>> * They will use this timeout as the time to wait for a free >>> connection. No, see above. >>> * They will use this timeout as the time to wait for a >>> response from the back end servers. Yes, for mod_proxy_ajp, no for mod_proxy_http until you have applied r546128 (http://svn.apache.org/viewvc?view=rev&rev=546128). If you have not applied r546128 (2.2.4) mod_proxy_http will use the Timeout setting of the virtual server. >>> >>> Everything but the last bullet item of (2) is crystal clear from the >>> documentation. That last bullet was clear as mud to me from the >>> docs, though. As said the documentation needs some improvements here. Regards Rüdiger
