Thanks a lot. This is very useful information. I will soon post my complete config.
Thanks, 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, 3:28 PM > On 14.07.2009 10:41, Madhuri > Patwardhan wrote: > > 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? > > The socket connect timeout is only used during > establishment of a new > connection to Tomcat. If there were no timeout, you could > run into long > tcp retransmits in some network problem situations. > > After a connection is established, you can use a general > socket timeout. > Some platforms do not support them though (e.g. Solaris) > and mod_jk > silently drops that timeout if it is not supported. I'm not > a fan of a > general socket timeout , because once such a timeout fires, > the > connection cannot be used any more. I do like more the > various ping > timeouts and if applicable to the app a reply timeout. > > > 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? > > REC means: this worker is now allowed for future requests. > The first > request, which could be balanced to it, will go there (and > set the > status to PRB for probing). During the execution of this > request the > worker will be not available for further request, until > that ne either > returns successfully (then the worker goes into OK), or it > returns with > an error, so the worker goes back to ERR. > > > Are the real new > > requests sent to the worker in ERR/REC state? > > Yes, at the moment we can only probe with real requests. > > > 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? > > It depends on where the request fails. If it fails early: > yes. If it is > a huge POST request and the data has already been sent to > the worker and > it fails during response generation, we will no longer have > the huge > request body at hand to send to some other worker. > > But in moist situations the failure will be detectable > either during TCP > connect or the following ping test. So both are very > important to activate! > > > 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? > > You can post your complete new config for check. Most of > the timeouts > are off by default in order to make newer jk versions > behave compatible > with older ones, even if that behaviour wasn't optimal. So > activate the > timeouts (and use version 1.2.28). > > Finally add %D to your Apache LogFormat. It's the response > time in > microseconds and lets you fid out, when and for what > requests things > start to go wrong. Also add a couple of the log notes > mentioned in > > http://tomcat.apache.org/connectors-doc/reference/apache.html > > (like e.g. JK_LB_FIRST_NAME, JK_LB_LAST_NAME, > JK_LB_LAST_ERRORS, > JK_LB_LAST_BUSY, JK_LB_LAST_ACCESSED). > > Regards, > > Rainer > > > --- 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
