-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steffen,
On 9/19/2011 4:49 AM, steffen.scheu...@fiducia.de wrote: > If one out of 6 balanced Tomcat-Server, throws an > OutOfMemory-Error, mod_jk doestn´t distribute any Reqeuest to the > other Servers, until we restart the faultet Server or stop the > Server via jkstatus. > > Here is a sample of the mod_jk-Logfile, while our Server1 got an > OutOfMemoryError. From 10:15 to 10:22 non of the other Servers was > distributet by mod_jk, even tough they had no problem at all. > > [snip] > > [Mon Sep 05 10:15:07 2011] [26959:22] [error] > ajp_send_request::jk_ajp_common.c (1585): (Server1) connecting to > backend failed. Tomcat is probably not started or is listening on > the wrong port (errno=145) The good thing is that mod_jk could detect the error. I was going to guess that Tomcat continued to return 200 responses or something foolish like that. This ought to be easier to fix than what I was fearing. > I made an analysis, about the Number of Requests processed by each > Server per Minute: > > Timest. Srv1 Srv2 Srv3 Srv4 Srv5 Srv6 10:08, 750 821 829 792 > 796 754 10:09, 677 630 624 635 617 647 10:10, 598 641 604 605 598 > 624 10:11, 573 551 592 547 560 585 10:12, 634 613 616 628 662 623 > 10:13, 680 708 634 617 735 771 10:14, 10 546 521 450 437 409 So, 10 requests were sent to Server1 during this minute? That sounds reasonable, given: > workerServer1.retry_interval=100 That means that mod_jk will try 10 times per second to reach Server1 when it's in an error state. > 10:22, 56 238 243 261 250 247 10:23, 10 728 742 716 740 761 56 seems high, but that might be due to multiple httpd workers all re-trying. > 10:24, 0 671 638 649 669 608 At this point, it looks like mod_jk has finally given up on the worker. What did the Tomcat status worker say at this point for the worker "Server1"? > 10:54, 686 549 562 506 529 548 So, this is when Server1 becomes operational again? Did you have to use the status worker to trigger mod_jk to allow it back into the cluster, or did it recover on it's own? Do you know if the [error] messages in mod_jk.log above actually correspond to client connection failures, or are they just notices that one member of the cluster dropped-out? > workers.properties Configuration: > > worker.loadbalancer.type=lb > worker.loadbalancer.balance_workers=Server1,Server2,Server3,Server4,Server5,Server6,Server7,Server8 > > worker.loadbalancer.sticky_session=True > worker.loadbalancer.sticky_session_force=False > worker.loadbalancer.method=Request > worker.loadbalancer.lock=Optimistic You might want to set "retries" here. > ######################################################################### > > # Worker loadbalancer Server1 # > ######################################################################### > > worker.Server1.type=ajp13 workerServer1.host=Server1.mydomain > workerServer1.port=8800 workerServer1.socket_timeout=600 > workerServer1.socket_keepalive=0 workerServer1.retries=7 > workerServer1.retry_interval=100 > workerServer1.connection_pool_timeout=600 > workerServer1.lbfactor=100 workerServer1.connect_timeout=3000 > workerServer1.prepost_timeout=3000 workerServer1.reply_timeout=0 > workerServer1.recovery_options=0 workerServer1.activation=Active > workerServer1.route=Server1 workerServer1.domain=Server1 > workerServer1.redirect=- Several thoughts: 0. You are missing dots (but you told Andre that it was a huge typo... not sure how that kind of typo happens). 1. You should look into using "template" workers. 2. Unless you really want to explicitly set all those properties, don't set anything that is the same as a documented default. There's no reason to specify all those details. > ######################################################################### > > # Worker loadbalancer Server2 # > ######################################################################### > > worker.Server1.type=ajp13 workerServer1.host=Server1.mydomain Another huge typo? You might want to consider configuring mod_jk to use a "ping_mode" for activation management. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk53ZBsACgkQ9CaO5/Lv0PA3MwCfWTOGRC5fHXgIbDr0vfbI2Aq/ EqUAn0ei7EtsqCW/iNkIhSOylVfc4odP =NlXi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
