Re: mod_jk - connectionTimeout en connection_pool_timeout

2007-09-10 Thread Henk Fictorie

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

2007-09-06 Thread Henk Fictorie

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]



Re: mod_jk - connectionTimeout en connection_pool_timeout

2007-09-06 Thread Rainer Jung

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)

   
protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" />



On the tomcat 5.5 site the connectionTimeout is set to 10 minutes:



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]



mod_jk - connectionTimeout en connection_pool_timeout

2007-09-06 Thread Henk Fictorie

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.
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


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)




On the tomcat 5.5 site the connectionTimeout is set to 10 minutes:



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

-- 
View this message in context: 
http://www.nabble.com/mod_jk---connectionTimeout-en-connection_pool_timeout-tf4390617.html#a12518264
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]