Hi Rainer, By shutdown I mean I have clicked the 'stop' link on the tomcat manager page.
Im also using session replication between the two tomcats. I have just tried turning off firefoxes cache and I see the same result. On 7/30/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > Hi Ben, > > I don't know what exactly you mean by "shutdown", but mod_jk has no > memory/cache/buffer for parts or all of an earlier response. It does > buffer parts of a request for reusing it during failover, but not with > responses and not between different requests. > > If the webapp is not available on the target system, there is no way how > mod_jk could return with 50 lines of correct response. Those 50 lines > might either come from your backend (what is "shutdown"), or from some > other cache (browser, between browser and Apache, mod_cache_* inside > Apache, between Apache and Tomcat). > > Nevertheless for production, I would always use a cleaner way of > disabling a context: before undeploying first set the activation of the > worker to stooped, which means it will no longer forward any requests > and the load balancer will transparantly choose another worker. No > recovery and errors. > > If you use sessions without replication, you could also set a worker to > disabled before going into stopped. With disabled requests for existing > sessions will still be forwarded, but no requests without sessions. > Depending on your session timing the target might thus get slowly out of > use. > > Also add timeouts to your config. We have a new docs page for 1.2.24 > (which will go live tomorrow). You can have a look at it under > > http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.24/generic_howto/timeouts.html > > and consider using the option recovery_options. > > Regards, > > Rainer > > > ben short wrote: > > Hi, > > > > I have a odd issue occurring with my tomcat cluster serving ~50 lines > > of the page from a stopped webapp. > > > > My setup is as follows... > > > > Box 1 > > > > Apache running a jk mod loadbalancer. It loadbalances between an > > instance of tomcat on this box and on box 2. > > > > Box 2 > > > > Apache running a jk mod loadbalancer. It loadbalances between an > > instance of tomcat on this box and on box 1. > > > > Software... > > > > OS RH 4 > > Tomcat 6.0.13 > > Java 1.6.0_01 > > Apache 2.2.4 > > Mod_jk 1.2.23 > > > > workers.properties (same on both boxes) > > > > # JK Status worker config > > > > worker.list=jkstatus > > worker.jkstatus.type=status > > > > # Presentaton Load Balancer Config > > > > worker.list=preslb > > > > worker.preslb.type=lb > > worker.preslb.balance_workers=jcpres1,jcpres2 > > worker.preslb.sticky_session=0 > > > > worker.jcpres1.port=8009 > > worker.jcpres1.host=192.168.6.171 > > worker.jcpres1.type=ajp13 > > worker.jcpres1.lbfactor=1 > > worker.jcpres1.fail_on_status=503,400,500,909 > > > > worker.jcpres2.port=8009 > > worker.jcpres2.host=192.168.6.174 > > worker.jcpres2.type=ajp13 > > worker.jcpres2.lbfactor=1 > > worker.jcpres2.fail_on_status=503,400,500,909 > > > > > > My problem... > > > > If i stop the webapp on box 2, wait for a while and make a request I > > get about 50 lines of the expected page in my browser ( assuming the > > request went to the shutdown webapp. On checking the jkstatus page I > > then see that the lb has set that webapp to ERR. On refreshing the > > browser the lb routes me to the running webapp and I get the expected > > page. > > After a while the jk lb will set the shutdown webapp into the REC > > state. If I then make another request I see the same thing, about 50 > > lines of a page and then the lb kicks the lb member out of the lb > > pool. > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
