You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Hubert de Heer <hd...@mirabeau.nl> on 2009/02/02 15:35:14 UTC
mod_jk 1.2.27 strange default reply_timeout
Hi,
We have an environment running Apache 2.2.9, mod_jk 1.2.27 and Tomcat
5.5.27.
The following settings are in place:
Apache (prefork mode)
=====================
Timeout 60
KeepAliveTimeout 5
JkWatchdogInterval 90
JkOptions +DisableReuse
worker.properties
=================
worker.host_1.type=ajp13
worker.host_1.host=127.0.0.1
worker.host_1.port=8009
worker.host_1.socket_keepalive=1
worker.host_1.socket_timeout=15
worker.host_1.connect_timeout=10000
worker.host_1.prepost_timeout=8000
worker.host_1.lbfactor=1
worker.host_1.ping_mode=A
worker.host_1.connection_pool_timeout=600
server.xml
==========
<Connector port="8009"
maxThreads="750" minSpareThreads="25" maxSpareThreads="75"
connectionTimeout="600000"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
What we notice is that Apache will respond with an error 502 Bad Gateway
when a response takes more than 30sec.
This seems quite strange as without a reply_timeout set I would expect
the reply_timeout to default to 0 (timeout disabled).
The same setup with mod_jk 1.2.26 does not give this 502 Bad Gateway
error, can't find any information on a behavioural change regarding
reply timeouts.
The error from mod_jk logging:
[Mon Feb 02 13:45:18 2009] [8645:3086362304] [info]
ajp_connection_tcp_get_message::jk_ajp_common.c (1111): (host_1) can't
receive the response message from tomcat, network problems or tomcat
(127.0.0.1:8009) is down (errno=11)
[Mon Feb 02 13:45:18 2009] [8645:3086362304] [error]
ajp_get_reply::jk_ajp_common.c (1920): (host_1) Tomcat is down or
refused connection. No response has been sent to the client (yet)
[Mon Feb 02 13:45:18 2009] [8645:3086362304] [info]
ajp_service::jk_ajp_common.c (2407): (host_1) sending request to tomcat
failed (recoverable), (attempt=2)
[Mon Feb 02 13:45:18 2009] [8645:3086362304] [error]
ajp_service::jk_ajp_common.c (2426): (host_1) connecting to tomcat
failed.
[Mon Feb 02 13:45:18 2009] host_1 127.0.0.1 "POST
/hv/main/nav/processflightqry HTTP/1.1" 34.101650
Regards,
Hubert de Heer
Re: mod_jk 1.2.27 strange default reply_timeout
Posted by Mladen Turk <mt...@apache.org>.
Hubert de Heer wrote:
> Hi,
>
> Thanks for the quick answer.
> So the main difference between socket_timeout and socket_connect_timeout is that the later only affects the connect phase.
Correct.
> I rolled back to mod_jk 1.2.26 but will try 1.2.27 with socket_connect_timeout tomorrow.
> Any advice on whether I should forget about the socket_timeout or not? What would be recommendable for a production environment?
>
It depends. Socket timeout is supposed to be used to enforce
the application responsiveness. If it happens, it usually means
that you have either too slow backend box or you've set
your expectations too high :)
There are some usages where the application response time
is mandatory, and other nodes should be tried if one is
too slow.
The second one is more pragmatic.
If the socket_timeout is infinite, the httpd ServerTimeout
will kill the client connection, so you will get different
error.log message then the actual reason was.
So set the socket_timeout to some lower value (eg 90%)
of ServerTimeout.
In majority of cases you won't need the socket_timeout,
because with balancer you should use cping/cpong and
reply_timeout, that will handle most of the issues.
connect_timeout however will improve the overall
responsiveness in cases when backend nodes refuse the
connections (eg. too high connection count or simply dead)
Hope this helps a bit.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: mod_jk 1.2.27 strange default reply_timeout
Posted by Hubert de Heer <hd...@mirabeau.nl>.
Hi,
Thanks for the quick answer.
So the main difference between socket_timeout and socket_connect_timeout is that the later only affects the connect phase.
I rolled back to mod_jk 1.2.26 but will try 1.2.27 with socket_connect_timeout tomorrow.
Any advice on whether I should forget about the socket_timeout or not? What would be recommendable for a production environment?
PS we're running RHEL ES 4 lastest update.
Regards,
Hubert
-----Original Message-----
From: Mladen Turk [mailto:mturk@apache.org]
Sent: Mon 02/02/2009 6:16 PM
To: Tomcat Users List
Subject: Re: mod_jk 1.2.27 strange default reply_timeout
Hubert de Heer wrote:
> Hi,
>
>
> worker.host_1.socket_timeout=15
>
This is the root of the problem
cause it imposes the timeout on any socket operation
between mod_jk and tomcat.
>
>
> What we notice is that Apache will respond with an error 502 Bad Gateway
> when a response takes more than 30sec.
>
socket_timeout x 2 (one op and one retry)
> This seems quite strange as without a reply_timeout set I would expect
> the reply_timeout to default to 0 (timeout disabled).
>
This is to have infinite socket_timeout and
still have reply timeout.
Note that socket_timeout is fixed with 1.2.27, so
it actually works now ;)
With 1.2.27 you have a new
socket_connect_timeout property that you can set
to a lower value (see the changelog and docs)
Regards
--
^(TM)
Re: mod_jk 1.2.27 strange default reply_timeout
Posted by Mladen Turk <mt...@apache.org>.
Hubert de Heer wrote:
> Hi,
>
>
> worker.host_1.socket_timeout=15
>
This is the root of the problem
cause it imposes the timeout on any socket operation
between mod_jk and tomcat.
>
>
> What we notice is that Apache will respond with an error 502 Bad Gateway
> when a response takes more than 30sec.
>
socket_timeout x 2 (one op and one retry)
> This seems quite strange as without a reply_timeout set I would expect
> the reply_timeout to default to 0 (timeout disabled).
>
This is to have infinite socket_timeout and
still have reply timeout.
Note that socket_timeout is fixed with 1.2.27, so
it actually works now ;)
With 1.2.27 you have a new
socket_connect_timeout property that you can set
to a lower value (see the changelog and docs)
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org