You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jess Holle <je...@ptc.com> on 2007/06/15 19:23:24 UTC
ProxyTimeout Revisited
Currently one can specify timeout on one's BalancerMember (e.g. with
mod_proxy_ajp).
Does this serve as both a connection and request timeout? If so, in the
worst case I can use it to be both and thus set it for the latter
(knowing it is ridiculous for the former).
I read the "Re: ProxyTimeout does not work as documented
<http://marc.info/?l=apache-httpd-dev&m=117986243317037&w=2>" thread and
am trying to figure out how to set connection and request timeouts for
mod_proxy_ajp today with 2.2.4 -- and hopefully do so in a manner that
is compatible with the resolution of this thread...
--
Jess Holle
Re: ProxyTimeout Revisited
Posted by Ruediger Pluem <rp...@apache.org>.
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
Re: ProxyTimeout Revisited
Posted by Ruediger Pluem <rp...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: ProxyTimeout Revisited
Posted by Jess Holle <je...@ptc.com>.
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,
>
> I think the documentation does not correctly document the code for the
> a) part!
>
> 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.
>> * They will wait for ProxyTimeout or 300 seconds for a
>> response from the back end servers.
>> 2. If a timeout is specified on proxy workers:
>> * They will use this timeout as the time to wait for a free
>> connection.
>> * They will use this timeout as the time to wait for a
>> response from the back end servers.
>>
>> 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.
>>
>> --
>> Jess Holle
>
Re: ProxyTimeout Revisited
Posted by Rainer Jung <ra...@kippdata.de>.
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,
I think the documentation does not correctly document the code for the
a) part!
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.
> * They will wait for ProxyTimeout or 300 seconds for a
> response from the back end servers.
> 2. If a timeout is specified on proxy workers:
> * They will use this timeout as the time to wait for a free
> connection.
> * They will use this timeout as the time to wait for a
> response from the back end servers.
>
> 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.
>
> --
> Jess Holle
Re: ProxyTimeout Revisited
Posted by Jess Holle <je...@ptc.com>.
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.
* They will wait for ProxyTimeout or 300 seconds for a
response from the back end servers.
2. If a timeout is specified on proxy workers:
* They will use this timeout as the time to wait for a free
connection.
* They will use this timeout as the time to wait for a
response from the back end servers.
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.
--
Jess Holle
Re: ProxyTimeout Revisited
Posted by Jess Holle <je...@ptc.com>.
Hmmm....
The documentation says:
timeout |Timeout| Connection timeout in seconds. If not set the
Apache will wait until the free connection is available. This
directive is used for limiting the number of connections to the
backend server together with |max| parameter.
Yet the discussion thread at
http://marc.info/?l=apache-httpd-dev&m=117986243317037&w=2 seems to say
that "timeout" on the workers will be used as a connection and/or
request -- and then fallback to ProxyTimeout and finally to Timeout.
Essentially I'm looking to transform:
<Proxy balancer://ajpWorker>
BalancerMember ajp://localhost:8010 min=15 max=300 smax=30
ttl=900 keepalive=Off timeout=86400
</Proxy>
into something that will:
1. Wait essentially indefinitely for a response from a backend Tomcat
(e.g. up to a day 86400).
2. Wait up to a different time period, e.g. 180 seconds, to find a
worker rather than immediately returning a 503.
It's not at all clear to me how both are achieved in 2.2.4 and how both
will be achieved "shortly" when the changes discussed in the "Re:
ProxyTimeout does not work as documented" thread are backed into a 2.2.x
release (or if they will be).
--
Jess Holle
Rainer Jung wrote:
> As I understand mod_proxy_* and APR code, the BalancerManager timeout
> will set a timeout for individual read and write attempts to backend
> connections.
>
> So it neither correlates to an idle timeout on the connection (see ttl
> and smax) neither to a request timeout in the sense of a limit to the
> full request handling time.
>
> The timeout starts whenever something is expected to get read or
> written. So most of the times it should fire, when retrieving the
> initial response packets takes longer than this timeout, or your
> backend starts to hang in the middle of request processing.
>
> Regards,
>
> Rainer
>
> Jess Holle wrote:
>> Currently one can specify timeout on one's BalancerMember (e.g. with
>> mod_proxy_ajp).
>>
>> Does this serve as both a connection and request timeout? If so, in
>> the worst case I can use it to be both and thus set it for the latter
>> (knowing it is ridiculous for the former).
>>
>> I read the "Re: ProxyTimeout does not work as documented
>> <http://marc.info/?l=apache-httpd-dev&m=117986243317037&w=2>" thread
>> and am trying to figure out how to set connection and request
>> timeouts for mod_proxy_ajp today with 2.2.4 -- and hopefully do so in
>> a manner that is compatible with the resolution of this thread...
>>
>> --
>> Jess Holle
>
Re: ProxyTimeout Revisited
Posted by Rainer Jung <ra...@kippdata.de>.
As I understand mod_proxy_* and APR code, the BalancerManager timeout
will set a timeout for individual read and write attempts to backend
connections.
So it neither correlates to an idle timeout on the connection (see ttl
and smax) neither to a request timeout in the sense of a limit to the
full request handling time.
The timeout starts whenever something is expected to get read or
written. So most of the times it should fire, when retrieving the
initial response packets takes longer than this timeout, or your backend
starts to hang in the middle of request processing.
Regards,
Rainer
Jess Holle wrote:
> Currently one can specify timeout on one's BalancerMember (e.g. with
> mod_proxy_ajp).
>
> Does this serve as both a connection and request timeout? If so, in the
> worst case I can use it to be both and thus set it for the latter
> (knowing it is ridiculous for the former).
>
> I read the "Re: ProxyTimeout does not work as documented
> <http://marc.info/?l=apache-httpd-dev&m=117986243317037&w=2>" thread and
> am trying to figure out how to set connection and request timeouts for
> mod_proxy_ajp today with 2.2.4 -- and hopefully do so in a manner that
> is compatible with the resolution of this thread...
>
> --
> Jess Holle