<html><head><META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>The Apache Tomcat Connector - Generic HowTo - Timeouts HowTo</title><meta value="Rainer Jung" name="author"><meta value="rjung@apache.org" name="email"><link rel="stylesheet" type="text/css" href="../style.css"></head><body vlink="#525D76" alink="#525D76" link="#525D76" text="#000000" bgcolor="#ffffff"><table cellspacing="4" width="100%" border="0"><!--PAGE HEADER--><tr><td colspan="2"><!--TOMCAT LOGO--><a href="http://tomcat.apache.org/"><img border="0" alt="Apache Tomcat" align="left" src="../images/tomcat.gif"></a><!--APACHE LOGO--><a href="http://www.apache.org/"><img border="0" alt="Apache Logo" align="right" src="http://www.apache.org/images/asf-logo.gif"></a></td></tr><!--HEADER SEPARATOR--><tr><td colspan="2"><hr size="1" noshade></td></tr><tr><!--LEFT SIDE NAVIGATION--><td nowrap="true" valign="top" width="20%"><p><strong>Links</strong></p><ul><li><a href="../index.html">Docs Home</a></li></ul><p><strong>Reference Guide</strong></p><ul><li><a href="../reference/workers.html">workers.properties</a></li><li><a href="../reference/uriworkermap.html">uriworkermap.properties</a></li><li><a href="../reference/status.html">Status Worker</a></li><li><a href="../reference/apache.html">Apache</a></li><li><a href="../reference/iis.html">IIS</a></li></ul><p><strong>Generic HowTo</strong></p><ul><li><a href="../generic_howto/quick.html">For the impatient</a></li><li><a href="../generic_howto/workers.html">All about workers</a></li><li><a href="../generic_howto/timeouts.html">Timeouts</a></li><li><a href="../generic_howto/loadbalancers.html">Load Balancing</a></li></ul><p><strong>Webserver HowTo</strong></p><ul><li><a href="../webserver_howto/apache.html">Apache</a></li><li><a href="../webserver_howto/iis.html">IIS</a></li><li><a href="../webserver_howto/nes.html">Netscape/SunOne/Sun</a></li></ul><p><strong>AJP Protocol Reference</strong></p><ul><li><a href="../ajp/ajpv13a.html">AJPv13</a></li><li><a href="../ajp/ajpv13ext.html">AJPv13 Extension Proposal</a></li></ul><p><strong>Miscellaneous Documentation</strong></p><ul><li><a href="../miscellaneous/faq.html">Frequently asked questions</a></li><li><a href="../miscellaneous/changelog.html">Changelog</a></li><li><a href="http://issues.apache.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Tomcat+5&component=Native%3AJK&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Current Native:JK bugs</a></li><li><a href="../miscellaneous/doccontrib.html">Contribute documentation</a></li><li><a href="../miscellaneous/jkstatustasks.html">JK Status Ant Tasks</a></li><li><a href="../miscellaneous/reporttools.html">Reporting Tools</a></li><li><a href="http://tomcat.apache.org/connectors-doc-archive/jk2/index.html">Old JK/JK2 documentation</a></li></ul><p><strong>News</strong></p><ul><li><a href="../news/20070301.html">2007</a></li><li><a href="../news/20060101.html">2006</a></li><li><a href="../news/20050101.html">2005</a></li><li><a href="../news/20041100.html">2004</a></li></ul></td><!--RIGHT SIDE MAIN BODY--><td align="left" valign="top" width="80%"><table cellspacing="4" width="100%" border="0"><tr><td valign="top" align="left"><h1>The Apache Tomcat Connector - Generic HowTo</h1><h2>Timeouts HowTo</h2></td><td nowrap="true" valign="top" align="right"><small><a href="printer/timeouts.html"><img alt="Printer Friendly Version" border="0" src="../images/printer.gif"><br>print-friendly<br>version
</a></small></td></tr></table><table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#525D76"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Introduction"><strong>Introduction</strong></a></font></td></tr><tr><td><blockquote>
<br>
<p>Setting communication timeouts is very important to improve the
communication process. They help to detect problems and stabilize
a distributed system. JK can use several different timeout types, which
can be individually configured. For historical reasons, all of them are
disabled by default. This HowTo explains their use and gives
hints how to find appropriate values.
</p>
<p>All timeouts can be configured in the workers.properties file.
For a complete reference of all worker configuration
items, please consult the worker <a href="../reference/workers.html">reference</a>.
This page assumes, that you are using at least version 1.2.16 of JK.
Dependencies on newer versions will be mentioned where necessary.
</p>
<p><font color="#ff0000">
Do not set timeouts to extreme values. Very small timeouts will likely
be counterproductive.
</font></p>
<p><font color="#ff0000">
Long Garbage Collection pauses on the backend do not make a good
fit with some timeouts. Try to optimize your Java memory and GC settings.
</font></p>
</blockquote></td></tr></table><table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#525D76"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="JK timeout attributes"><strong>JK timeout attributes</strong></a></font></td></tr><tr><td><blockquote>
<br>
<table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#828DA6"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="CPing/CPong"><strong>CPing/CPong</strong></a></font></td></tr><tr><td><blockquote>
<p>
CPing/CPong is our notion for using small test packets to check the
status of backend connections. JK can use such test packets directly after establishing
a new backend connection and also directly before each request gets send to a backend.
The maximum waiting time for a CPong answer to a CPing can be configured.
</p>
<p>
The test packets will be answered by the backend very fast with a minimal amount of
needed processing resources. A positive answer tells us, that the backend can be reached
and is actively processing requests. It does not detect, if some context is deployed
and working. The benefit of CPing/CPong is a fast detection of a communication
problem with the backend. The downside is a slightly increased laterncy.
</p>
<p>
The worker attribute <b>connect_timeout</b> sets the wait timeout for CPong during
connection establishment. By default the value is "0", which disables CPing/CPong during
connection establishment. Since JK usually uses persistent connections, opening new connections
is a rare event. We therefore recommend using <b>connect_timeout</b>. Its value is given
in milliseconds. Depending on your network latency and stability, good values often
are between 5000 and 15000 milliseconds. Remember: don't use extremely small values.
</p>
<p>
The worker attribute <b>prepost_timeout</b> sets the wait timeout for CPong before
request forwarding. By default the value is "0", which disables CPing/CPong before
request forwarding. Activating this type of CPing/CPong adds a small latency to each
request. Usually this is small enough and the benefit of CPing/CPong is more important.
In general we also recommend using <b>prepost_timeout</b>. Its value is given
in milliseconds. Depending on your network latency and stability, good values often
are between 5000 and 10000 milliseconds. Remember: don't use extremely small values.
</p>
</blockquote></td></tr></table>
<table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#828DA6"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Low-Level TCP Timeouts"><strong>Low-Level TCP Timeouts</strong></a></font></td></tr><tr><td><blockquote>
<p>
Some platforms allow to set timeouts for all operations on TCP sockets.
This is available for Linux and Windows, other patforms do not support this,
e.g. Solaris. If your platform supports TCP send and receive timeouts,
you can set them using the worker attribute <b>socket_timeout</b>.
You can not set the two wimeouts to different values.
</p>
<p>
JK will accept this attribute even if your platform does not support
socket timeouts. In this case setting the attribute will have no effect.
By default the value is "0" and the timeout is disabled.
You can set the attribute to some seconds value (not: milliseconds).
JK will then set the send and the receive timeouts of the backend
connections to this value. The timeout is low-level, it is
used for each read and write operation on the socket individually.
</p>
<p>
Using this attribute will make JK react faster to some types of network problems.
Unfortunately socket timeouts have negative side effects, because for most
platforms, there is no good way to recover from such a timeout, once it fired.
For JK there is no way to decide, if this timeout fired because of real network
problems, or only because it didn't receive an answer packet from a backend in time.
So remember: don't use extremely small values.
</p>
</blockquote></td></tr></table>
<table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#828DA6"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Connection Pools and Idle Timeouts"><strong>Connection Pools and Idle Timeouts</strong></a></font></td></tr><tr><td><blockquote>
<p>
JK handles backend connections in a connection pool per web server process.
The connections are used in a persistent mode. After a request completed
successfully we keep the connection open and wait for the next
request to forward. The connection pool is able to grow according
to the number of threads that want to forward requests in parallel.
</p>
<p>
Most applications have a varying load depending on the hour of the day
or the day of the month. Other reasons for a growing connection pool
would be temporary slowness of backends, leading to an increasing
congestion of the frontends like web servers. Many backends use a dedicated
thread for each incoming connection they handle. So usually one wants the
connection pool to shrink, if the load diminishes.
</p>
<p>
JK allows connections in the pool to get closed after some idle time.
This maximum idle time can be configured with the attribute
<b>connection_pool_timeout</b> which is given in units of seconds.
The default value is "0", which disables closing idle connections.
</p>
<p>
We generally recommend values around 10 minutes, so setting
<b>connection_pool_timeout</b> to 600 (seconds). If you use this attribute,
please also set the attribute <b>connectionTimeout</b> in the AJP
Connector element of your Tomcat server.xml configuration file to
an analogous value. <b>Caution</b>: connectionTimeout is in milliseconds.
So if you set JK connection_pool_timeout to 600, you should set Tomcat
connectionTimeout to 600000.
</p>
<p>
JK connections do not get closed immediately after the timeout passed.
Instead there is an automatic internal maintenance task
running every 60 seconds, that checks the idle status of all connections.
The 60 seconds interval
can be adjusted with the global attribute worker.maintain. We do not
recommend to change this value, because it has a lot of side effects.
The maintenance task only runs, if requests get processed. So if your web
server has processes that do not receive any requests for a long
time, there is no way to close the idle connections in its pool.
</p>
<p>
The maximum connection pool size can be configured with the
attribute <b>connection_pool_size</b>. We generally do not recommend
to use this attribute in combination with Apache httpd. For
Apache httpd we automatically detect the number of threads per
process and set the maximum pool size to this value. For IIS we use
a default value of 250, for the Sun Web Server the default is "1".
We recommend adjusting this value for IIS and the Sun Web Server
to the number of requests one web server process should
be able to send to a backend in parallel.
</p>
<p>
The JK attribute <b>connection_pool_minsize</b> defines,
how many idle connections remain when the pool gets shrinked.
By default this is half of the maximum pool size.
</p>
</blockquote></td></tr></table>
<table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#828DA6"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Firewall Connection Dropping"><strong>Firewall Connection Dropping</strong></a></font></td></tr><tr><td><blockquote>
<p>
One particular problem with idle connections comes from firewalls, that
are often deployed between the web server layer and the backend.
Depending on their configuration, they will silently drop
connections from their status table if they are idle for to long.
</p>
<p>
From the point of view of JK and of the web server, the other side
simply doesn't answer any traffic. Since TCP is a reliable protocol
it detects the missing TCP ACKs and tries to resend the packets for
a relatively long time, typically several minutes.
</p>
<p>
Many firewalls will allow connection closing, even if they dropped
the connection for normal traffic. Therefore you should always use
<a href="#Connection Pools and Idle Timeouts">connection_pool_timeout and
connection_pool_minsize</a> on the JK side
and connectionTimeout on the Tomcat side.
</p>
<p>
Furthermore using the boolean attribute <b>socket_keepalive</b> you can
set a standard socket option, that automatically sends TCP keepalive packets
after some idle time on each connection. By default this is set to "False".
If you suspect idle connection drops by firewalls you should set this to
"True".
</p>
<p>
Unfortunately the default intervals and algorithms for these packets
are platform specific. You might need to inspect TCP tuning options for
your platform on how to control TCP keepalive.
Often the default intervals are much longer than the firewall timeouts
for idle connections. Nevertheless we recommend talking to your firewall
administration and your platform administration in order to make them agree
on good configuration values for the firewall and the platform TCP tuning.
</p>
<p>
In case none of our recommendations help and you are definitively having
problems with idle connection drops, you can disable the use of persistent
connections when using JK together with Apache httpd. For this you set
"JkOptions +DisableReuse" in your Apache httpd configuration.
This will have a huge negative performance impact!
</p>
</blockquote></td></tr></table>
<table width="100%" cellpadding="2" cellspacing="0" border="0"><tr><td bgcolor="#828DA6"><font face="arial,helvetica.sanserif" color="#ffffff"><a name="Reply Timeout"><strong>Reply Timeout</strong></a></font></td></tr><tr><td><blockquote>
<p>
JK can also use a timeout on request replies. This timeout does not
measure the full processing time of the response. Instead it controls,
how much time between consecutive response packets is allowed.
</p>
<p>
In most cases, this is what one actually wants. Consider for example
long running downloads. You would not be able to set an effective global
reply timeout, because downloads could last for many minutes.
Most applications though have limited processing time before starting
to return the response. For those applications you could set an explicit
reply timeout. Applications that do not harmonize with reply timeouts
are batch type applications, data warehouse and reporting applications
which are expected to observe long processing times.
</p>
<p><font color="#ff0000">
If JK aborts waiting for a response, because a reply timeout fired,
there is no way to stop processing on the backend. Although you free
processing ressources in your web server, the request
will continue to run on the backend - without any way to send back a
result once the reply timout fired.
</font></p>
<p>
JK uses the worker attribute <b>reply_timeout</b> to set reply timeouts.
The default value is "0" (timeout disabled) and you can set it to any
millisecond value.
</p>
<p>
In combination with a load balancing worker, JK will disable a member
worker of the load balancer if a reply timeout fires. The worker will then
no longer be used until it gets recovered during the next automatic
maintenance task. Starting with JK 1.2.24 you can improve this behaviour using
<b><a href="../reference/workers.html">max_reply_timeouts</a></b>. This
attribute will allow occasional long running requests without disabling the
worker. Only if those requests happen to often, the worker gets disabled by the
load balancer.
</p>
</blockquote></td></tr></table>
</blockquote></td></tr></table></td></tr><!--FOOTER SEPARATOR--><tr><td colspan="2"><hr size="1" noshade></td></tr><!--PAGE FOOTER--><tr><td colspan="2"><div align="center"><font size="-1" color="#525D76"><em>
Copyright © 1999-2005, Apache Software Foundation
</em></font></div></td></tr></table></body></html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
ca35d3a5ce53ec398ef5c5041608cec0
>
files
>
16
