tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: 2 second delays in mod_jk while "maintaining workers"
Date Tue, 07 Sep 2010 10:09:46 GMT
On 07.09.2010 11:36, John Baker wrote:
> Rainer,
>
> Is this acceptable?  I am using a tail and an egrep to match the various statements you
wish to see.  if it's missing anything, plesae let me know what to add to the grep.

Yes, that's better!

> [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] find_match::jk_uri_worker_map.c
(850): Attempting to map context URI '/*=lb-jboss51-integration' source 'JkMount'
> [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] find_match::jk_uri_worker_map.c
(863): Found a wildchar match '/*=lb-jboss51-integration'
> [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] jk_handler::mod_jk.c (2462):
Into handler jakarta-servlet worker=lb-jboss51-integration r->proxyreq=0
> [Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug] wc_get_worker_for_name::jk_worker.c
(116): found a worker lb-jboss51-integration
> [Tue Sep 07 10:20:20.618 2010] [18806:46962404156768] [debug] jk_shutdown_socket::jk_connect.c
(722): About to shutdown socket 154
> [Tue Sep 07 10:20:22.619 2010] [18806:46962404156768] [debug] jk_shutdown_socket::jk_connect.c
(813): Shutdown socket 154 and read 0 lingering bytes in 2 sec.

Hmmm, that's strange. Why is there a connection close between 
wc_get_worker_for_name() and wc_maintain()? The first call doing 
something with the connections would be wc_maintain(). And if it decides 
to close sockets, it would log addiional statements. Nevertheless we can 
see, that closing the socket really took 2 seconds (which is in fact a 
builtin mod_jk timeout).

Are we sure, that those log lines are correct? This was generated by 
mod_jk 1.2.30 without any code changes, right?

Log level trace would show us more precisely, how we came to close the 
socket, but it blows up log volume a lot.

> [Tue Sep 07 10:20:22.625 2010] [18806:46962404156768] [debug] wc_maintain::jk_worker.c
(339): Maintaining worker lb-jboss51-integration
> [Tue Sep 07 10:20:22.628 2010] [18806:46962404156768] [debug] get_most_suitable_worker::jk_lb_worker.c
(1001): found best worker jboss51-integration1 (jboss51-integration1) using method 'Request'
> [Tue Sep 07 10:20:22.628 2010] [18806:46962404156768] [debug] service::jk_lb_worker.c
(1161): service worker=jboss51-integration1 route=jboss51-integration1
> [Tue Sep 07 10:20:22.628 2010] [18806:46962404156768] [debug] ajp_service::jk_ajp_common.c
(2376): processing jboss51-integration1 with 1 retries
> [Tue Sep 07 10:20:22.628 2010] [18806:46962404156768] [debug] ajp_send_request::jk_ajp_common.c
(1579): (jboss51-integration1) all endpoints are disconnected.
> [Tue Sep 07 10:20:22.631 2010] [18806:46962404156768] [debug] ajp_send_request::jk_ajp_common.c
(1639): (jboss51-integration1) request body to send 0 - request body to resend 0
> [Tue Sep 07 10:20:22.637 2010] [18806:46962404156768] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c
(1336): 0030    5F 2E 6A 62 6F 73 73 35 31 2D 69 6E 74 65 67 72  - _.jboss51-integr
> [Tue Sep 07 10:20:22.638 2010] [18806:46962404156768] [debug] ajp_unmarshal_response::jk_ajp_common.c
(723): Header[0] [Set-Cookie] = [JSESSIONID=cM2w+W7dIfDERfQpzO6BDw__.jboss51-integration1;
Path=/xx]
> [Tue Sep 07 10:20:22.640 2010] [18806:46962404156768] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c
(1336): 0160    5F 2E 6A 62 6F 73 73 35 31 2D 69 6E 74 65 67 72  - _.jboss51-integr
> ..
> [Tue Sep 07 10:20:22.651 2010] [18806:46962404156768] [debug] ajp_reset_endpoint::jk_ajp_common.c
(757): (jboss51-integration1) resetting endpoint with sd = 154
> [Tue Sep 07 10:20:22.651 2010] [18806:46962404156768] [debug] ajp_done::jk_ajp_common.c
(3010): recycling connection pool slot=0 for worker jboss51-integration1
> [Tue Sep 07 10:20:22.651 2010] [18806:46962404156768] [debug] jk_handler::mod_jk.c (2602):
Service finished with status=200 for worker=lb-jboss51-integration
>
> To confirm the settings:
>
> worker.basic.connection_pool_timeout=90

You don't usually want to set a pool_size. "1" would be appropriate when 
using the prefork Apache MPM, but in that case mod_jk automatically sets 
it to "1".

> worker.basic.connection_pool_size=1
> worker.basic.socket_keepalive=1

I don't like "socket_timeout" ...

> worker.basic.socket_timeout=90

but I would like socket_connect_timeout.

The next two are possibly a bit short, because if the backend e.g. does 
a Java Garbage Collection which miht take longer than 1 second, tose 
timeouts will fire and take the  node out of load balancing.

> worker.basic.connect_timeout=1000
> worker.basic.prepost_timeout=1000

You might want to add max_reply_timeouts, otherwise one single reply 
timeout can take a node out of load balancing.

> worker.basic.reply_timeout=90000
> # Stop recoery attempts when JBoss instances do not respond.
> worker.basic.retries=1
> worker.basic.recovery_options=27
>
> worker.jboss51-integration1.reference=worker.basic
> worker.jboss51-integration1.host=xx
> worker.jboss51-integration1.port=13802
> worker.jboss51-integration1.type=ajp13
> worker.jboss51-integration1.lbfactor=1
> worker.jboss51-integration2.reference=worker.basic
> worker.jboss51-integration2.host=yy
> worker.jboss51-integration2.port=13802
> worker.jboss51-integration2.type=ajp13
> worker.jboss51-integration2.lbfactor=1
> worker.lb-jboss51-integration.type=lb
> worker.lb-jboss51-integration.balance_workers=jboss51-integration1,jboss51-integration2

Don't want sticky sessions?

> worker.lb-jboss51-integration.sticky_session=0
> worker.list=lb-jboss51-integration
>
> Also, I've tried setting:
>
> worker.basic.lock=0
>
> but that does not solve the problem.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message