According to online documentation (http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html): ---- Long Garbage Collection pauses on the backend do not make a good fit with some timeouts. Try to optimise your Java memory and GC settings. ----
So if JVM tuning doesn't help, what else could I do? Balancer worker's method=Busyness setting may have some effect, but still this is different. What do you think? Thanks, Sean On Tue, Apr 20, 2010 at 12:48 PM, Sean GAO <gaoyuxi...@gmail.com> wrote: > Hi, > > We are running apache 2.2.4 and tomcat 5.5.28 with mod_jk 1.2.28. 3 > tomcat instances. > > Referring to http://tomcat.apache.org/connectors-doc/reference/workers.html > , we came up with a workers.properties file like this: > > worker.list=balancer > worker.maintain=30 > #tomcat01 > worker.tomcat01.port=18009 > worker.tomcat01.host=localhost > worker.tomcat01.type=ajp13 > worker.tomcat01.lbfactor=120 > worker.tomcat01.retries=2 > worker.tomcat01.socket_timeout=30 > worker.tomcat01.reply_timeout=30000 > worker.tomcat01.recover_time=300 > #tomcat02 > worker.tomcat02.port=28009 > worker.tomcat02.host=localhost > worker.tomcat02.type=ajp13 > worker.tomcat02.lbfactor=100 > worker.tomcat02.retries=2 > worker.tomcat02.socket_timeout=30 > worker.tomcat02.reply_timeout=30000 > worker.tomcat02.recover_time=300 > #tomcat03 > worker.tomcat03.port=38009 > worker.tomcat03.host=localhost > worker.tomcat03.type=ajp13 > worker.tomcat03.lbfactor=0 > worker.tomcat03.retries=2 > #loadbalancer > worker.retries=2 > worker.balancer.type=lb > worker.balancer.sticky_session=False > worker.balancer.method=Busyness > worker.balancer.balance_workers=tomcat01,tomcat02,tomcat03 > > So basically tomcat01 and tomcat02 are the main request handlers, with > tomcat03 acting as a backup server which is accessed only when both > tomcat01 and tomcat02 are in error state (30 seconds without response, > not necessarily mean offline). If something bad happens, e.g. > excessively long GC, or redeployment, we assume each failed tomcat > instance to get back to business in about 5 minutes. > > This meets our needs to a certain degree. However, there's one thing > that bugs me: > If we set the reply_timeout too high, we miss the whole point of > fail-over. If we set the value too low, it's likely we are going to > kill a lot of legitimate/would-otherwise-success request, which is not > what we wanted either. > > Instead of breaking the long request (say, >30 seconds) and put the > worker into "error" state, is there anyway, anyway at all, we can tell > mod_jk to mark a worker "busy", so that future requests are routed to > alternative workers? mok_jk can still check every 30 (or the default > 60) seconds whether it is able to resume one of the "busy"-marked > workers, just like it does with the ones in "error" state. > > > Regards, > Sean > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
