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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
