Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Rainer, I setup a test httpd + loadbalancer with jk 1.2.24 and could reproduce the problem over and over again. Then I patched the source and have been unable to reproduce the problem with the patched mod_jk.so. So the patch looks good. Regards Ben On 8/1/07, ben short [EMAIL PROTECTED] wrote: I'll give it ago first thing tomorrow, well after a cup of tea :) On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: hi Ben, could you try the following patch for 1.2.24: http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch I guess you can build the module yourself (it's easy: configure --with-apxs=PATHTOAPXS; make; make install). Now simply download the source of 1.2.24 and use the patch command to add the above file as a patch. Then build and retest. If you really can't build it yourself let me know. The patch is not well tested, don't go straight to production with it :) Regards, Rainer ben short wrote: Sure for stable operation, but what if the machine reboots, tomcat starts up and your webapp doesn't for some reason. This situation could occur then. Many thanks for your help with this one. Regards Ben On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: Hi Ben, I think I understand the problem now, and it is a jk bug. For stable operation you should really use the disable/stop feature. Nevertheless I'm starting thinking about how to fix this in a good way. The bug has to do with the new fail on status feature you use. It is not very old, so we didn't experience the bug before. Stay tuned ... Regards, Rainer - 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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Hi Ben, I think I understand the problem now, and it is a jk bug. For stable operation you should really use the disable/stop feature. Nevertheless I'm starting thinking about how to fix this in a good way. The bug has to do with the new fail on status feature you use. It is not very old, so we didn't experience the bug before. Stay tuned ... Regards, Rainer ben short wrote: Is length 1090 correct?`So does the full body have that length? Yes firefox reports that the page is 1k in size, via the web developer's tool bar. I have seen it happen in IE 6 and 7 also. Would it be possible for me to email you directly the output of wireshark for both one bad and one good attempt? I really appreciate you helping me out on this one. Regards Ben Short On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: ben short wrote: Ok I have used wireshark and see that the request is sent to the apache httpd. The next first packet i get back contains the following... HTTP/1.1 200 OK Date: Tue, 31 Jul 2007 14:57:25 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23 Content-Length: 1090 ***NOTE every line but this has a \r\n shown in the middle frame of wireshark *** All Headers are supposed to end with \r\n, but I would find it very strange, if this does not do it (I can not really think of a reson for that, but who knows...) Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Language: en-GB Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 Is length 1090 correct?`So does the full body have that length? !--Rail Timestamp: -- !--Generated by Journeycheck 4.0-RC5 on host jc-pres2.nexusalpha.com -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=english .head ..meta http-equiv=Content-Type content=text/html;charset=UTF-8/ ..meta http-equiv=expires content=0/ ..meta http-equiv=cache-control content=no-cache/ ..meta http-equiv=pragma content=nocache/ ..meta http-equiv=Content-Language content=en-us/ ..meta content=Nexus Alpha:Andrew Langmead, Ben Short, Lawrence Chan name=author/ ..meta content=journey check,rail,journey,nexus alpha,plan,disruption,transport,trains name=keywords/ ..meta content=Allows you to check your journey with a particular rail company name=description/ ..!--META HTTP-EQUIV=RefreshCONTENT=10; URL=http://www.jcheck.com/firstcapitalconnect/;-- .. ..link href=/resources/common/web/css/common.css rel=stylesheet type=text/css/ ..!--script type=text/javascript src=/resources/common/web/javascript Which is whats being shown in the browser, if i view the source. Next I see more packets that say 'Continuation or non-HTTP traffic' in the Info column of wireshark. When I look at the byte output I can see that its the rest of the page. If i use wireshark to view the same request with the webapp started I dont see the initial HTTP/1.1 200 OK packet, so i assume that each packet contains the correct headers for chunking to work correctly. But the first line is mandatory for HTTP responses! So in the good case, something is slipping the observation. We could ignore that, but if we don't see something in the good case, we must question the observation in the bad case too. So it seams that im getting a dodgy content length in the first packet if the request goes to the stoppped webapp first. Or infact the whole chunking thing is not working correctly. If there is a Cntent-Length header, there is no chunking involved. Chunking gives a way of telling the length of small chunks of the answer. For dynamic content it's often difficult to tell the full length in advance, but a Content-Length header has to come before the body. So chunking is used to prevent the need of buffering the full body before sending it out. The reposnse you showed us above does not use chunking, but instead the content-length header, which is OK and stable for content with easy to determine length. Which browser is it? If you can reproduce the problem with firefox, there are very good plugins, that can show you details of communication and content from inside the browser. A good example is FireBug, which I can recommend. Even if you usually use MSIE, it might be important to cross check with Firefox in order to find out if the problem is browser specific. Regards, Rainer On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: You could dig deeper into two different directions: - protocol: is the content-length in the response headers correct? Or does it use chunked transfer, and is this OK? - sniff the network in front of the apache: do the packets actually get send back to the browser? Regards, Rainer ben short wrote: I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Sure for stable operation, but what if the machine reboots, tomcat starts up and your webapp doesn't for some reason. This situation could occur then. Many thanks for your help with this one. Regards Ben On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: Hi Ben, I think I understand the problem now, and it is a jk bug. For stable operation you should really use the disable/stop feature. Nevertheless I'm starting thinking about how to fix this in a good way. The bug has to do with the new fail on status feature you use. It is not very old, so we didn't experience the bug before. Stay tuned ... Regards, Rainer ben short wrote: Is length 1090 correct?`So does the full body have that length? Yes firefox reports that the page is 1k in size, via the web developer's tool bar. I have seen it happen in IE 6 and 7 also. Would it be possible for me to email you directly the output of wireshark for both one bad and one good attempt? I really appreciate you helping me out on this one. Regards Ben Short On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: ben short wrote: Ok I have used wireshark and see that the request is sent to the apache httpd. The next first packet i get back contains the following... HTTP/1.1 200 OK Date: Tue, 31 Jul 2007 14:57:25 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23 Content-Length: 1090 ***NOTE every line but this has a \r\n shown in the middle frame of wireshark *** All Headers are supposed to end with \r\n, but I would find it very strange, if this does not do it (I can not really think of a reson for that, but who knows...) Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Language: en-GB Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 Is length 1090 correct?`So does the full body have that length? !--Rail Timestamp: -- !--Generated by Journeycheck 4.0-RC5 on host jc-pres2.nexusalpha.com -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=english .head ..meta http-equiv=Content-Type content=text/html;charset=UTF-8/ ..meta http-equiv=expires content=0/ ..meta http-equiv=cache-control content=no-cache/ ..meta http-equiv=pragma content=nocache/ ..meta http-equiv=Content-Language content=en-us/ ..meta content=Nexus Alpha:Andrew Langmead, Ben Short, Lawrence Chan name=author/ ..meta content=journey check,rail,journey,nexus alpha,plan,disruption,transport,trains name=keywords/ ..meta content=Allows you to check your journey with a particular rail company name=description/ ..!--META HTTP-EQUIV=RefreshCONTENT=10; URL=http://www.jcheck.com/firstcapitalconnect/;-- .. ..link href=/resources/common/web/css/common.css rel=stylesheet type=text/css/ ..!--script type=text/javascript src=/resources/common/web/javascript Which is whats being shown in the browser, if i view the source. Next I see more packets that say 'Continuation or non-HTTP traffic' in the Info column of wireshark. When I look at the byte output I can see that its the rest of the page. If i use wireshark to view the same request with the webapp started I dont see the initial HTTP/1.1 200 OK packet, so i assume that each packet contains the correct headers for chunking to work correctly. But the first line is mandatory for HTTP responses! So in the good case, something is slipping the observation. We could ignore that, but if we don't see something in the good case, we must question the observation in the bad case too. So it seams that im getting a dodgy content length in the first packet if the request goes to the stoppped webapp first. Or infact the whole chunking thing is not working correctly. If there is a Cntent-Length header, there is no chunking involved. Chunking gives a way of telling the length of small chunks of the answer. For dynamic content it's often difficult to tell the full length in advance, but a Content-Length header has to come before the body. So chunking is used to prevent the need of buffering the full body before sending it out. The reposnse you showed us above does not use chunking, but instead the content-length header, which is OK and stable for content with easy to determine length. Which browser is it? If you can reproduce the problem with firefox, there are very good plugins, that can show you details of communication and content from inside the browser. A good example is FireBug, which I can recommend. Even if you usually use MSIE, it might be important to cross check with Firefox in order to find out if the problem is browser specific. Regards, Rainer On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: You could dig deeper into two different directions: - protocol: is the
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
hi Ben, could you try the following patch for 1.2.24: http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch I guess you can build the module yourself (it's easy: configure --with-apxs=PATHTOAPXS; make; make install). Now simply download the source of 1.2.24 and use the patch command to add the above file as a patch. Then build and retest. If you really can't build it yourself let me know. The patch is not well tested, don't go straight to production with it :) Regards, Rainer ben short wrote: Sure for stable operation, but what if the machine reboots, tomcat starts up and your webapp doesn't for some reason. This situation could occur then. Many thanks for your help with this one. Regards Ben On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: Hi Ben, I think I understand the problem now, and it is a jk bug. For stable operation you should really use the disable/stop feature. Nevertheless I'm starting thinking about how to fix this in a good way. The bug has to do with the new fail on status feature you use. It is not very old, so we didn't experience the bug before. Stay tuned ... Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
I'll give it ago first thing tomorrow, well after a cup of tea :) On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: hi Ben, could you try the following patch for 1.2.24: http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch I guess you can build the module yourself (it's easy: configure --with-apxs=PATHTOAPXS; make; make install). Now simply download the source of 1.2.24 and use the patch command to add the above file as a patch. Then build and retest. If you really can't build it yourself let me know. The patch is not well tested, don't go straight to production with it :) Regards, Rainer ben short wrote: Sure for stable operation, but what if the machine reboots, tomcat starts up and your webapp doesn't for some reason. This situation could occur then. Many thanks for your help with this one. Regards Ben On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote: Hi Ben, I think I understand the problem now, and it is a jk bug. For stable operation you should really use the disable/stop feature. Nevertheless I'm starting thinking about how to fix this in a good way. The bug has to do with the new fail on status feature you use. It is not very old, so we didn't experience the bug before. Stay tuned ... Regards, Rainer - 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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Rainer, Thanks for that. Yes we are going for a mix of both really. But I'll run some bench marks against both sticky and none sticky to see how it gets on. Yes in production if we want to stop/undeploy/deploy a webapp we will set the worker status to stopped. This issue came up as more of a what if test. Regards Ben On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Using sticky sessions will allow only requests without sessions to be balanced freely. If you've either got many sessions, or your sessions are relatively short, than load balancing will statistically still good. Only in case of few long lasting sessions, you could experience the problem, that some heavy-use sessions might go to the same node. In case you've got only two nodes and you are building an HA infrastructure, the optimality of the load balancing is not important, because one node needs to be able to carry the full load anyhow. Throughput oriented webapps balance best with method Request. Most installations I know observe a good load balancing although they are using stickyness. I would rate a deviation of +/- 15% load difference relative to the arithmetic mean over a 10 minute interval as good. Periods of low load don't count at all. Regards, Rainer ben short wrote: So how does setting sticky sessions to true and the default value for the Load Balancing Directive 'method' (defaults to request) interact then? On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Apart from all the other things I wrote: don't turn off session stickyness, even if you use replication. Turn it off only, if you've got a really good reason. The fact that switching the backend between requests is possible with replication should not lead to the assumption, that it is a good idea to do this continuously. ben short wrote: 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
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
I have altered the code to write out which webapp generated the page to the html, so i can see where the partial responses are comming from. What I see is I stop the webapp on box 2. I make a request and I see part of the page. The html shows that the partial page was generated by the running webapp on box 1. On a slightly different note, I have the mod_jk logging set to debug. When it logs out the packets that its received from the webapps it doesn't show all the html page. For instance I see two full packets traced out then a half full one and that's it. But the page renders ok in the browser. I have a example log if anyone would like to see it. On 7/31/07, ben short [EMAIL PROTECTED] wrote: Rainer, Thanks for that. Yes we are going for a mix of both really. But I'll run some bench marks against both sticky and none sticky to see how it gets on. Yes in production if we want to stop/undeploy/deploy a webapp we will set the worker status to stopped. This issue came up as more of a what if test. Regards Ben On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Using sticky sessions will allow only requests without sessions to be balanced freely. If you've either got many sessions, or your sessions are relatively short, than load balancing will statistically still good. Only in case of few long lasting sessions, you could experience the problem, that some heavy-use sessions might go to the same node. In case you've got only two nodes and you are building an HA infrastructure, the optimality of the load balancing is not important, because one node needs to be able to carry the full load anyhow. Throughput oriented webapps balance best with method Request. Most installations I know observe a good load balancing although they are using stickyness. I would rate a deviation of +/- 15% load difference relative to the arithmetic mean over a 10 minute interval as good. Periods of low load don't count at all. Regards, Rainer ben short wrote: So how does setting sticky sessions to true and the default value for the Load Balancing Directive 'method' (defaults to request) interact then? On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Apart from all the other things I wrote: don't turn off session stickyness, even if you use replication. Turn it off only, if you've got a really good reason. The fact that switching the backend between requests is possible with replication should not lead to the assumption, that it is a good idea to do this continuously. ben short wrote: 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
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
ben short wrote: I have altered the code to write out which webapp generated the page to the html, so i can see where the partial responses are comming from. What I see is I stop the webapp on box 2. I make a request and I see part of the page. The html shows that the partial page was generated by the running webapp on box 1. On a slightly different note, I have the mod_jk logging set to debug. When it logs out the packets that its received from the webapps it doesn't show all the html page. For instance I see two full packets traced out then a half full one and that's it. But the page renders ok in the browser. I have a example log if anyone would like to see it. Log level debug truncates packet dump to I think 1KB, log level trace shows all of the packets. Maybe interesting for you: the ReplicationValve has two configurable attributes, that allow you to detect from the app, if the request went to the same node as the last request of the same session before, i.e. if a failover happended. The first attribute is primaryIndicator (Default: false), if set to true, it will enable this feature. When the feature is enabled, there is an additional request attribute (not: parameter), with name org.apache.catalina.ha.tcp.isPrimarySession (this is a string name) and its value is a Boolean, true if the request went to the sticky node, false, if it switched nodes. The name of the request attribute can be changed from the default org.apache.catalina.ha.tcp.isPrimarySession to something else, by setting the attribute primaryIndicatorName=myname for the ReplicationValve. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes the full page to the response. I can then see it all in the mod_jk logs. But the browser only shows a partial page. On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: ben short wrote: I have altered the code to write out which webapp generated the page to the html, so i can see where the partial responses are comming from. What I see is I stop the webapp on box 2. I make a request and I see part of the page. The html shows that the partial page was generated by the running webapp on box 1. On a slightly different note, I have the mod_jk logging set to debug. When it logs out the packets that its received from the webapps it doesn't show all the html page. For instance I see two full packets traced out then a half full one and that's it. But the page renders ok in the browser. I have a example log if anyone would like to see it. Log level debug truncates packet dump to I think 1KB, log level trace shows all of the packets. Maybe interesting for you: the ReplicationValve has two configurable attributes, that allow you to detect from the app, if the request went to the same node as the last request of the same session before, i.e. if a failover happended. The first attribute is primaryIndicator (Default: false), if set to true, it will enable this feature. When the feature is enabled, there is an additional request attribute (not: parameter), with name org.apache.catalina.ha.tcp.isPrimarySession (this is a string name) and its value is a Boolean, true if the request went to the sticky node, false, if it switched nodes. The name of the request attribute can be changed from the default org.apache.catalina.ha.tcp.isPrimarySession to something else, by setting the attribute primaryIndicatorName=myname for the ReplicationValve. Regards, Rainer - 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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
You could dig deeper into two different directions: - protocol: is the content-length in the response headers correct? Or does it use chunked transfer, and is this OK? - sniff the network in front of the apache: do the packets actually get send back to the browser? Regards, Rainer ben short wrote: I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes the full page to the response. I can then see it all in the mod_jk logs. But the browser only shows a partial page. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Ok I have used wireshark and see that the request is sent to the apache httpd. The next first packet i get back contains the following... HTTP/1.1 200 OK Date: Tue, 31 Jul 2007 14:57:25 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23 Content-Length: 1090 ***NOTE every line but this has a \r\n shown in the middle frame of wireshark *** Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Language: en-GB Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 !--Rail Timestamp: -- !--Generated by Journeycheck 4.0-RC5 on host jc-pres2.nexusalpha.com -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=english .head ..meta http-equiv=Content-Type content=text/html;charset=UTF-8/ ..meta http-equiv=expires content=0/ ..meta http-equiv=cache-control content=no-cache/ ..meta http-equiv=pragma content=nocache/ ..meta http-equiv=Content-Language content=en-us/ ..meta content=Nexus Alpha:Andrew Langmead, Ben Short, Lawrence Chan name=author/ ..meta content=journey check,rail,journey,nexus alpha,plan,disruption,transport,trains name=keywords/ ..meta content=Allows you to check your journey with a particular rail company name=description/ ..!--META HTTP-EQUIV=RefreshCONTENT=10; URL=http://www.jcheck.com/firstcapitalconnect/;-- .. ..link href=/resources/common/web/css/common.css rel=stylesheet type=text/css/ ..!--script type=text/javascript src=/resources/common/web/javascript Which is whats being shown in the browser, if i view the source. Next I see more packets that say 'Continuation or non-HTTP traffic' in the Info column of wireshark. When I look at the byte output I can see that its the rest of the page. If i use wireshark to view the same request with the webapp started I dont see the initial HTTP/1.1 200 OK packet, so i assume that each packet contains the correct headers for chunking to work correctly. So it seams that im getting a dodgy content length in the first packet if the request goes to the stoppped webapp first. Or infact the whole chunking thing is not working correctly. On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: You could dig deeper into two different directions: - protocol: is the content-length in the response headers correct? Or does it use chunked transfer, and is this OK? - sniff the network in front of the apache: do the packets actually get send back to the browser? Regards, Rainer ben short wrote: I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes the full page to the response. I can then see it all in the mod_jk logs. But the browser only shows a partial page. - 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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
ben short wrote: Ok I have used wireshark and see that the request is sent to the apache httpd. The next first packet i get back contains the following... HTTP/1.1 200 OK Date: Tue, 31 Jul 2007 14:57:25 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23 Content-Length: 1090 ***NOTE every line but this has a \r\n shown in the middle frame of wireshark *** All Headers are supposed to end with \r\n, but I would find it very strange, if this does not do it (I can not really think of a reson for that, but who knows...) Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Language: en-GB Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 Is length 1090 correct?`So does the full body have that length? !--Rail Timestamp: -- !--Generated by Journeycheck 4.0-RC5 on host jc-pres2.nexusalpha.com -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=english .head ..meta http-equiv=Content-Type content=text/html;charset=UTF-8/ ..meta http-equiv=expires content=0/ ..meta http-equiv=cache-control content=no-cache/ ..meta http-equiv=pragma content=nocache/ ..meta http-equiv=Content-Language content=en-us/ ..meta content=Nexus Alpha:Andrew Langmead, Ben Short, Lawrence Chan name=author/ ..meta content=journey check,rail,journey,nexus alpha,plan,disruption,transport,trains name=keywords/ ..meta content=Allows you to check your journey with a particular rail company name=description/ ..!--META HTTP-EQUIV=RefreshCONTENT=10; URL=http://www.jcheck.com/firstcapitalconnect/;-- .. ..link href=/resources/common/web/css/common.css rel=stylesheet type=text/css/ ..!--script type=text/javascript src=/resources/common/web/javascript Which is whats being shown in the browser, if i view the source. Next I see more packets that say 'Continuation or non-HTTP traffic' in the Info column of wireshark. When I look at the byte output I can see that its the rest of the page. If i use wireshark to view the same request with the webapp started I dont see the initial HTTP/1.1 200 OK packet, so i assume that each packet contains the correct headers for chunking to work correctly. But the first line is mandatory for HTTP responses! So in the good case, something is slipping the observation. We could ignore that, but if we don't see something in the good case, we must question the observation in the bad case too. So it seams that im getting a dodgy content length in the first packet if the request goes to the stoppped webapp first. Or infact the whole chunking thing is not working correctly. If there is a Cntent-Length header, there is no chunking involved. Chunking gives a way of telling the length of small chunks of the answer. For dynamic content it's often difficult to tell the full length in advance, but a Content-Length header has to come before the body. So chunking is used to prevent the need of buffering the full body before sending it out. The reposnse you showed us above does not use chunking, but instead the content-length header, which is OK and stable for content with easy to determine length. Which browser is it? If you can reproduce the problem with firefox, there are very good plugins, that can show you details of communication and content from inside the browser. A good example is FireBug, which I can recommend. Even if you usually use MSIE, it might be important to cross check with Firefox in order to find out if the problem is browser specific. Regards, Rainer On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: You could dig deeper into two different directions: - protocol: is the content-length in the response headers correct? Or does it use chunked transfer, and is this OK? - sniff the network in front of the apache: do the packets actually get send back to the browser? Regards, Rainer ben short wrote: I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes the full page to the response. I can then see it all in the mod_jk logs. But the browser only shows a partial page. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Is length 1090 correct?`So does the full body have that length? Yes firefox reports that the page is 1k in size, via the web developer's tool bar. I have seen it happen in IE 6 and 7 also. Would it be possible for me to email you directly the output of wireshark for both one bad and one good attempt? I really appreciate you helping me out on this one. Regards Ben Short On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: ben short wrote: Ok I have used wireshark and see that the request is sent to the apache httpd. The next first packet i get back contains the following... HTTP/1.1 200 OK Date: Tue, 31 Jul 2007 14:57:25 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23 Content-Length: 1090 ***NOTE every line but this has a \r\n shown in the middle frame of wireshark *** All Headers are supposed to end with \r\n, but I would find it very strange, if this does not do it (I can not really think of a reson for that, but who knows...) Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Language: en-GB Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 Is length 1090 correct?`So does the full body have that length? !--Rail Timestamp: -- !--Generated by Journeycheck 4.0-RC5 on host jc-pres2.nexusalpha.com -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=english .head ..meta http-equiv=Content-Type content=text/html;charset=UTF-8/ ..meta http-equiv=expires content=0/ ..meta http-equiv=cache-control content=no-cache/ ..meta http-equiv=pragma content=nocache/ ..meta http-equiv=Content-Language content=en-us/ ..meta content=Nexus Alpha:Andrew Langmead, Ben Short, Lawrence Chan name=author/ ..meta content=journey check,rail,journey,nexus alpha,plan,disruption,transport,trains name=keywords/ ..meta content=Allows you to check your journey with a particular rail company name=description/ ..!--META HTTP-EQUIV=RefreshCONTENT=10; URL=http://www.jcheck.com/firstcapitalconnect/;-- .. ..link href=/resources/common/web/css/common.css rel=stylesheet type=text/css/ ..!--script type=text/javascript src=/resources/common/web/javascript Which is whats being shown in the browser, if i view the source. Next I see more packets that say 'Continuation or non-HTTP traffic' in the Info column of wireshark. When I look at the byte output I can see that its the rest of the page. If i use wireshark to view the same request with the webapp started I dont see the initial HTTP/1.1 200 OK packet, so i assume that each packet contains the correct headers for chunking to work correctly. But the first line is mandatory for HTTP responses! So in the good case, something is slipping the observation. We could ignore that, but if we don't see something in the good case, we must question the observation in the bad case too. So it seams that im getting a dodgy content length in the first packet if the request goes to the stoppped webapp first. Or infact the whole chunking thing is not working correctly. If there is a Cntent-Length header, there is no chunking involved. Chunking gives a way of telling the length of small chunks of the answer. For dynamic content it's often difficult to tell the full length in advance, but a Content-Length header has to come before the body. So chunking is used to prevent the need of buffering the full body before sending it out. The reposnse you showed us above does not use chunking, but instead the content-length header, which is OK and stable for content with easy to determine length. Which browser is it? If you can reproduce the problem with firefox, there are very good plugins, that can show you details of communication and content from inside the browser. A good example is FireBug, which I can recommend. Even if you usually use MSIE, it might be important to cross check with Firefox in order to find out if the problem is browser specific. Regards, Rainer On 7/31/07, Rainer Jung [EMAIL PROTECTED] wrote: You could dig deeper into two different directions: - protocol: is the content-length in the response headers correct? Or does it use chunked transfer, and is this OK? - sniff the network in front of the apache: do the packets actually get send back to the browser? Regards, Rainer ben short wrote: I'm not getting anywhere with this :( I have set the logging to trace for mod_jk and I can see all the response packets. I have also turned on our applications response logging and can see that the running webapp writes the full page to the response. I can then see it all in the mod_jk logs. But the browser only shows a partial page. - To start a new topic, e-mail:
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
So how does setting sticky sessions to true and the default value for the Load Balancing Directive 'method' (defaults to request) interact then? On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Apart from all the other things I wrote: don't turn off session stickyness, even if you use replication. Turn it off only, if you've got a really good reason. The fact that switching the backend between requests is possible with replication should not lead to the assumption, that it is a good idea to do this continuously. ben short wrote: 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]
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Using sticky sessions will allow only requests without sessions to be balanced freely. If you've either got many sessions, or your sessions are relatively short, than load balancing will statistically still good. Only in case of few long lasting sessions, you could experience the problem, that some heavy-use sessions might go to the same node. In case you've got only two nodes and you are building an HA infrastructure, the optimality of the load balancing is not important, because one node needs to be able to carry the full load anyhow. Throughput oriented webapps balance best with method Request. Most installations I know observe a good load balancing although they are using stickyness. I would rate a deviation of +/- 15% load difference relative to the arithmetic mean over a 10 minute interval as good. Periods of low load don't count at all. Regards, Rainer ben short wrote: So how does setting sticky sessions to true and the default value for the Load Balancing Directive 'method' (defaults to request) interact then? On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote: Apart from all the other things I wrote: don't turn off session stickyness, even if you use replication. Turn it off only, if you've got a really good reason. The fact that switching the backend between requests is possible with replication should not lead to the assumption, that it is a good idea to do this continuously. ben short wrote: 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
