On 19.03.2009 14:02, Jeff Fulmer wrote:
I'm having difficulty with failover testing. When a tomcat server goes
away due to networking issues, the site become effectively unusable.
Here's the architecture:
=> apache1 tomcat1
LB FW
=> apache2 tomcat2
If I stop the tomcat server tomcat2, there's no problem. It properly
closes the sockets and mod_jk/apache/linux knows the server went away. But
if I shutdown the network on tomcat2 (or yank the cable), mod_jk continues
to send packets to it. My socket table is filled with connections to
tomcat2:8009 in SYN_SENT. Apache continues to send every other request to
tomcat2. Since I use session stickiness, this only effects half the users
but still.
This should be handled by the socket_timeout, which you set to 2
minutes. How does it behave, if you reduce your socket timeout say to 10
seconds?
Peferrably you would use a recent JK. There you can tune the
socket_connect_timeout individually to something really small (soince
1.2.27).
Maybe you just want to test the latest 1.2.28 snapshot, We are very
close to the final 1.2.28 release (planned for tomorrow). The most
recent snapshot is available at
http://people.apache.org/~rjung/mod_jk-dev/source/jk-1.2.28-dev/tomcat-connectors-1.2.28-dev-756058-src.tar.gz
You can further tune error detection behaviour for 1.2.28 by setting
error_escalation_time to something small, you can even try "0".
Here's my workers.properties file:
ps=/
"ps" dos not have any meaning here. Simply delete it.
# Define list of workers that will be used
# for mapping requests
# When load-balancing is used, real workers should not be listed here.
worker.list=balancer,status
# Definte default worker settings
Using a template, so yes, you RTFM :)
worker.default.port=8009
worker.default.type=ajp13
worker.default.lbfactor=1
worker.default.socket_timeout=120
worker.default.reply_timeout=5000
5 seconds as a reply timeout is pretty ambitious. Without
max_reply_timeouts this means, that even a single request that takes
longer as 5 seconds to process will put the respective worker into an
error state.
worker.default.socket_keepalive=True
worker.default.ping_mode=P
worker.default.ping_timeout=5000
worker.default.connect_timeout=5000
worker.default.prepost_timeout=5000
ping_mode "P" does only do the prepost ping, so no need to set
connect_timeout (which is for another type of ping). You should also
drop the prepost_timeout, because you already have the mor egeneral
ping_timeout, and with your multiple definitions you and others might
woner, which of those settings are actually active.
worker.default.connection_pool_timeout=180
Remember to sync this with Tomcats connectionTimeout in the AJP
connector (but there its milliseconds and not seconds).
#------WORKER1-------
worker.worker1.reference=worker.default
worker.worker1.host=10.248.11.15
#------WORKER2-------
worker.worker2.reference=worker.default
worker.worker2.host=10.248.11.16
#------BALANCER------
worker.balancer.type=lb
worker.balancer.balance_workers=worker1,worker2
worker.balancer.sticky_session=true
worker.balancer.method=R
worker.balancer.lock=P
Locking should be fine with the default (optimistic). no more need for
pessimistic locking.
worker.balancer.sticky_session=1
t, T, true, True and 1 all are the same. You set thius attribute twice,
once above "True" and then here "1".
# Status worker for managing load balancer
worker.status.type=status
And here's my apache configuration:
<IfModule mod_jk.c>
JkWorkersFile /etc/httpd/conf/workers.properties
JkShmFile /var/log/httpd/mod_jk.shm
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkOptions +DisableReuse
You really want to use that? Better think about setting
connection_pool_minsize to "0" and activating the JkWatchdogInterval.
JkMount /rp/* balancer
JkMount /rp balancer
No mount for the status worker?
</IfModule>
Any thoughts?
TIA,
Jeff
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
