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
