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=revrev=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
