You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christian Schausberger <c....@oe24.at> on 2008/01/23 16:55:03 UTC
problem with mod_jk and tomcat-host downtime on solaris
Hi,
I use apache-2.2.4 together with mod_jk-1.2.25 to load balance a bunch
of tomcat-5.5.25 servers. All servers are running on Solaris 10 and are
implemented as zones.
The setup works really good during normal operation. But when a server
dies for some reason, and with it the zones running tomcat, mod_jk does
not stop sending requests to the unavailable tomcats until the operating
system times out the tcp connect. This takes more than a few minutes.
Reading the documentation suggests that socket_timeout is the appropiate
setting to deal with this problem but does not work on Solaris. I could
not find any usable settings in Solaris itself, so I am hoping this can
be solved with mod_jk configuration.
What is the correct way to have mod_jk recognize the tomcats as
unavailable more quickly on Solaris?
Below you can find my current mod_jk configuration.
Thanks
Christian
#############################################
# default worker list
worker.list=escenic,jkstatus
# worker template
worker.template.port=9009
worker.template.type=ajp13
worker.template.lbfactor=1
worker.template.socket_keepalive=0
worker.template.connect_timeout=10000
worker.template.reply_timeout=40000
worker.template.connection_pool_timeout=30
# workers definition
worker.escapp1.reference=worker.template
worker.escapp1.host=apppubl1.online.local
...
...
...
# load balancer definition
worker.escenic.type=lb
worker.escenic.max_reply_timeouts=3
worker.escenic.balance_workers=escapp1,escapp9,escapp3,escapp4,escapp5,escapp6,escapp7,escapp8
worker.escenic.sticky_session=1.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: problem with mod_jk and tomcat-host downtime on solaris
Posted by Christian Schausberger <c....@oe24.at>.
Rainer Jung wrote:
> Christian Schausberger wrote:
>> Rainer Jung wrote:
>>> I would start adding a prepost_timeout. See:
>>>
>>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>>> and
>>> http://tomcat.apache.org/connectors-doc/reference/workers.html
>>>
>> Maybe I misunderstood this directive. connect_timeout only applies after
>> the TCP connection has been established. I thought the order in which
>> those timeouts apply is:
>> 1.) socket_timeout
>> 2.) connect_timeout
>> 3.) prepost_timeout
>
> socket_timeout is a low level socket timeout (sic!).
> So whenever we read from the socket, the timer starts and if it fires,
> then we get an error. The connection can not be used any more afterwards.
If this is a matter of starting a timer after a read from the socket,
why should this not be supported on Solaris?
> prepost_timeout is similar to connect_timeout, but it is used in the
> situation, where the connection has already been established for some
> previous request and we are going to reuse (what we are supposed to do
> a lot, because AJP13 uses persistent connections). We send a cping and
> wait for cpong before each request when prepost_timeout is set. Such
> behaviour is very common with other persistent connection technologies
> like e.g. database connection pools.
>
>>
>> Does prepost_timeout actually work even though the underlying TCP
>> connection can not be established?
> See above, prepost gets used when we reuse an established connection
> to make sure, that the backend is still there and able to answer.
>
I have tried prepost as you suggested in your first reply but it had no
effect because of the reasons you just explained. Upgrading to
mod_jk-1.2.26 also had no effect. I assume reply_timeout will also rely
on an established ajp connection.
Regards,
Christian
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: problem with mod_jk and tomcat-host downtime on solaris
Posted by Rainer Jung <ra...@kippdata.de>.
Christian Schausberger wrote:
> Rainer Jung wrote:
>> I would start adding a prepost_timeout. See:
>>
>> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>> and
>> http://tomcat.apache.org/connectors-doc/reference/workers.html
>>
> Maybe I misunderstood this directive. connect_timeout only applies after
> the TCP connection has been established. I thought the order in which
> those timeouts apply is:
> 1.) socket_timeout
> 2.) connect_timeout
> 3.) prepost_timeout
socket_timeout is a low level socket timeout (sic!).
So whenever we read from the socket, the timer starts and if it fires,
then we get an error. The connection can not be used any more afterwards.
connect_timeout is higher level: *After* TCP connect we send a tiny
packet to Tomcat that is directly answered by the connector. We call it
cping/cpong. If this answer from Tomcat does not come back within the
connect_timeout, we think that we either are not connected to Tomcat or
it is stuck.
prepost_timeout is similar to connect_timeout, but it is used in the
situation, where the connection has already been established for some
previous request and we are going to reuse (what we are supposed to do a
lot, because AJP13 uses persistent connections). We send a cping and
wait for cpong before each request when prepost_timeout is set. Such
behaviour is very common with other persistent connection technologies
like e.g. database connection pools.
What I'm actually not sure about, is how short socket_timeout and longer
other timeouts go together. When we wait for cpong answers or a backend
reply, we use the select() call and I'm not sure if a socket_timeout
will fire during select (in our case it would be better if not).
>
> Does prepost_timeout actually work even though the underlying TCP
> connection can not be established?
See above, prepost gets used when we reuse an established connection to
make sure, that the backend is still there and able to answer.
>> Caution: there's a bug in 1.2.25 that makes max_reply_timouts useless.
>> Consider upgrading to 1.2.26 (even if this is not the solution to the
>> problem you are asking for).
> I will upgrade as soon as possible.
>
> Thanks,
>
> Christian
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: problem with mod_jk and tomcat-host downtime on solaris
Posted by Christian Schausberger <c....@oe24.at>.
Rainer Jung wrote:
> I would start adding a prepost_timeout. See:
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
> and
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
Maybe I misunderstood this directive. connect_timeout only applies after
the TCP connection has been established. I thought the order in which
those timeouts apply is:
1.) socket_timeout
2.) connect_timeout
3.) prepost_timeout
Does prepost_timeout actually work even though the underlying TCP
connection can not be established?
> Caution: there's a bug in 1.2.25 that makes max_reply_timouts useless.
> Consider upgrading to 1.2.26 (even if this is not the solution to the
> problem you are asking for).
I will upgrade as soon as possible.
Thanks,
Christian
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: problem with mod_jk and tomcat-host downtime on solaris
Posted by Rainer Jung <ra...@kippdata.de>.
Christian Schausberger wrote:
> Hi,
>
> I use apache-2.2.4 together with mod_jk-1.2.25 to load balance a bunch
> of tomcat-5.5.25 servers. All servers are running on Solaris 10 and are
> implemented as zones.
>
> The setup works really good during normal operation. But when a server
> dies for some reason, and with it the zones running tomcat, mod_jk does
> not stop sending requests to the unavailable tomcats until the operating
> system times out the tcp connect. This takes more than a few minutes.
>
> Reading the documentation suggests that socket_timeout is the appropiate
> setting to deal with this problem but does not work on Solaris. I could
> not find any usable settings in Solaris itself, so I am hoping this can
> be solved with mod_jk configuration.
>
> What is the correct way to have mod_jk recognize the tomcats as
> unavailable more quickly on Solaris?
I would start adding a prepost_timeout. See:
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
and
http://tomcat.apache.org/connectors-doc/reference/workers.html
Caution: there's a bug in 1.2.25 that makes max_reply_timouts useless.
Consider upgrading to 1.2.26 (even if this is not the solution to the
problem you are asking for).
>
> Below you can find my current mod_jk configuration.
>
> Thanks
>
> Christian
>
> #############################################
>
> # default worker list
> worker.list=escenic,jkstatus
>
> # worker template
> worker.template.port=9009
> worker.template.type=ajp13
> worker.template.lbfactor=1
> worker.template.socket_keepalive=0
> worker.template.connect_timeout=10000
> worker.template.reply_timeout=40000
> worker.template.connection_pool_timeout=30
>
> # workers definition
> worker.escapp1.reference=worker.template
> worker.escapp1.host=apppubl1.online.local
>
> ...
> ...
> ...
>
> # load balancer definition
> worker.escenic.type=lb
> worker.escenic.max_reply_timeouts=3
> worker.escenic.balance_workers=escapp1,escapp9,escapp3,escapp4,escapp5,escapp6,escapp7,escapp8
> worker.escenic.sticky_session=1.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org