Re: mod_jk - connectionTimeout en connection_pool_timeout
Changing to the default for retries fixed our problem. I still have one question. How does retries 1 work for a loadbalancer with sticky requests? A user started a session on a worker and got a jvmRoute to that worker in its session cookie. The worker fails and is put in error state. Will a sticky request for that worker be routed to another worker or will the request fail? regards Henk Henk Fictorie wrote: Rainer, Thanks for your response. You mentioned our setting of retries=1, so I reread the documentation to find out that it actually means 'no retries'. I have now commented out that line, so it will get the default value of 2. It will let you know if it helped. regards Henk -- View this message in context: http://www.nabble.com/mod_jk---connectionTimeout-en-connection_pool_timeout-tf4390617.html#a12591428 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - connectionTimeout en connection_pool_timeout
Hi Henk, Henk Fictorie wrote: Hi, We are using mod_jk 1.2.21 on Solaris 8. together Apache 2.0.59 with the worker MPM. We are moving our applicationserver to a new version which is also using a new Tomcat version. We now have a split application which is using both Tomcat 5.0 and the other part is using Tomcat 5.5. For tomcat 5.5 we set the connectionTimeout to 10 minutes, for 5.0 it is set to 0 (infinite) For Tomcat 5.0 we see lots more ESTABLISHED connections than for Tomcat 5.5. While I expected it to be the same. Hmmm. Maybe I'm missing the point, but I would not share your expectation: if you disable the idle connection timeout for TC 5.0, we will keep the idle connections around for a long time. OK, you've got an idle timeout on the JK side, but it will shrink the pool only until half of its maximum size. E.g. if you allow 25 threads per process with httpd, the pool will never shrink smaller than 13 connections (unless it didn't yet grow to this size) per process. Of course, since you didn't give us numbers, I'm not sure if this suffices to explain your observation. For the Tomcat 5.0 connections we do not see any errors (except for client errors). For the Tomcat 5.5 connections we see errors occuring, claiming that it cannot connect to Tomcat: [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1215): dummy) error sending request. Will try another pooled connection [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1241): (dummy) all endpoints are disconnected [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1244): (dummy) increase the backend idle connection timeout or the connection_pool_minsize [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_service::jk_ajp_common.c (1930): (dummy) sending request to tomcat failed, recoverable operation attempt=1 [Thu Sep 06 09:17:15 2007] [2735:0061] [error] ajp_service::jk_ajp_common.c (1942): (dummy) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port [Thu Sep 06 09:17:15 2007] [2735:0061] [info] service::jk_lb_worker.c (1023): service failed, worker dummy is in error state most of those are only info messages. They are telling us, that jk tried to use a connection, that has already been closed by Tomcat. Only the last line is an error. Usually a closed connection is not a problem, we simply search for another one in the connection cache. If we can't find an open connection, we use retry number 2 to open a new one. Since you set retries to 1, this will not happen. On the mod_jk side of things we use the same settings for both applications: worker.maintain=60 # worker template worker.template.type=ajp13 worker.template.port= worker.template.lbfactor=50 worker.template.connection_pool_timeout=600 worker.template.socket_timeout=62 worker.template.connect_timeout=3 worker.template.prepost_timeout=3 worker.template.recovery_options=0 worker.template.reply_timeout=60 worker.template.retries=1 On the tomcat 5.0 side the connectionTimeout is set to 0 (infinite) Connector className=org.apache.coyote.tomcat5.CoyoteConnector port= minProcessors=5 maxProcessors=500 acceptCount=10 debug=0 enableLookups=true redirectPort=8443 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler / On the tomcat 5.5 site the connectionTimeout is set to 10 minutes: Connector port= address=a.b.c.d enableLookups=false emptySessionPath=true minSpareThreads=20 maxThreads=750 acceptCount=10 connectionTimeout=60 redirectPort=8443 debug=0 protocol=AJP/1.3 / So, on the timeout settings for Tomcat 5.5 I am using the recommended values described in the 'timeouts howto' section. The info messages suggest that I should increase the connectionTimeout on the Tomcat side. Probably to some value (connection_pool_timeout + worker.maintain)?? Or should I set the connection_pool_minsize to match the minSpareThreads?? Or upgrade to mod_jk 1.2.25?? Advice is welcome. regards Henk Fictorie Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - connectionTimeout en connection_pool_timeout
Rainer, Thanks for your response. You mentioned our setting of retries=1, so I reread the documentation to find out that it actually means 'no retries'. I have now commented out that line, so it will get the default value of 2. It will let you know if it helped. regards Henk Rainer Jung-3 wrote: Hi Henk, Henk Fictorie wrote: Hi, We are using mod_jk 1.2.21 on Solaris 8. together Apache 2.0.59 with the worker MPM. We are moving our applicationserver to a new version which is also using a new Tomcat version. We now have a split application which is using both Tomcat 5.0 and the other part is using Tomcat 5.5. For tomcat 5.5 we set the connectionTimeout to 10 minutes, for 5.0 it is set to 0 (infinite) For the Tomcat 5.0 connections we do not see any errors (except for client errors). For the Tomcat 5.5 connections we see errors occuring, claiming that it cannot connect to Tomcat: [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1215): dummy) error sending request. Will try another pooled connection [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1241): (dummy) all endpoints are disconnected [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_send_request::jk_ajp_common.c (1244): (dummy) increase the backend idle connection timeout or the connection_pool_minsize [Thu Sep 06 09:17:15 2007] [2735:0061] [info] ajp_service::jk_ajp_common.c (1930): (dummy) sending request to tomcat failed, recoverable operation attempt=1 [Thu Sep 06 09:17:15 2007] [2735:0061] [error] ajp_service::jk_ajp_common.c (1942): (dummy) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port [Thu Sep 06 09:17:15 2007] [2735:0061] [info] service::jk_lb_worker.c (1023): service failed, worker dummy is in error state most of those are only info messages. They are telling us, that jk tried to use a connection, that has already been closed by Tomcat. Only the last line is an error. Usually a closed connection is not a problem, we simply search for another one in the connection cache. If we can't find an open connection, we use retry number 2 to open a new one. Since you set retries to 1, this will not happen. On the mod_jk side of things we use the same settings for both applications: worker.maintain=60 # worker template worker.template.type=ajp13 worker.template.port= worker.template.lbfactor=50 worker.template.connection_pool_timeout=600 worker.template.socket_timeout=62 worker.template.connect_timeout=3 worker.template.prepost_timeout=3 worker.template.recovery_options=0 worker.template.reply_timeout=60 worker.template.retries=1 regards Henk Fictorie Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/mod_jk---connectionTimeout-en-connection_pool_timeout-tf4390617.html#a12524923 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
