Thanks for the prompt reply. Yes. I did read the following howto document on timeout and also the mail thread http://www.mailinglistarchive.com/users@tomcat.apache.org/msg28345.html After reading the timeout howto once again, many things are becoming clear. Thanks for such a good document.
As I was reading the timeout howto once again, one question came to my mind. What is the difference between socket_timeout and socket_connect_timeout? socket_timeout is used for TCP send/receive timeouts. Does socket_connect_timeout indicate failure to establish socket connection? One question regardig recovery. Every maintainence period it tries to recover worker in ERR state. I see the state being changed to ERR/REC. What does it exactly do during recovery? Are the real new requests sent to the worker in ERR/REC state? At present, we have recorvey option, reply_timeout set to default. ping_mode is not set. If it does try a real new request with a worker during ERR/REC state and if request doesn't succeed then the request is sent to a good worker? We have mod_jk load balancer running in production. We are using load balancer with 19 mod_jk workers. We noticed that even though 10 out of 19 tomcat workers are in good state, some times web site is unresponsive for few minutes. Thats why, I was wondering if somehow the requests are still being sent to 9 workers which are in bad state. Perhaps, this is happening during the transition when a worker goes bad but it takes time for the load balancer to detect that. This was setup by somebody else and prepost_timeout, ping_mode, reply_timeout and recovery_options are not set. I am hoping that after setting these timeout values we will not see these issue. I will be setting these timeout values in production system, so are there anythings I should be careful about? Thanks a lot. Madhuri --- On Tue, 7/14/09, Rainer Jung <rainer.j...@kippdata.de> wrote: > From: Rainer Jung <rainer.j...@kippdata.de> > Subject: Re: reply timeout, connect_timeout and preprost_timeout values > To: "Tomcat Users List" <users@tomcat.apache.org> > Date: Tuesday, July 14, 2009, 2:14 AM > On 14.07.2009 04:34, Madhuri > Patwardhan wrote: > > Did you read the docs page about timeouts: > > http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html > > If you are very concerned about timeouts, use version > 1.2.28, because it > has an additional socket_connect_timeout. > > > connect_timeout and preprost_timeout what would be the > typical > > values? something like "5000" or less/more? > > I wouldn't choose less. The ping timeout usually shouldn't > fire. By > going to extremes, very small problems might lead to an > unacceptable big > reaction (taking a worker out of balancing, only because a > ping took a > second or so). > > Note, that in 1.2.28 there is an alternative unified way of > setting the > ping_timeout. > > > I also wonder if I specify prepost_timeout then it > would mean now > > each request would take that much additional > time?Before serving > > each request cping/cpong would be tried with timeout > value of > > prepost_timeout so that adds little delay to serving > the request?? > > Yes, before each request it adds a little latency, but > usually only very > few milliseconds, because the ping processing is very > simple. It adds > roughly double the network latency between your Apache and > Tomcat, which > for a normal LAN will be a single digit millisecond > number. > > I usually rate the improved stability higher than this > additional > resource use and latency. > > > Also, a typical value for recovery_options would be > "3". > > ... or "7". > > Concerning reply timeout: Also set max_reply_timeouts. > Don't push > reply_timeouts to low. In 1.2.28 you can set a general > reply_timeout and > set more specific ones for individual URL patterns, e.g. if > you have > some URLs that you expect to respond very sow (report > generation etc.). > This is done using extensions. See > > http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions > > Regards, > > Rainer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
