You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by ben short <ja...@gmail.com> on 2007/07/30 14:30:28 UTC
Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <ja...@gmail.com>.
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 <ja...@gmail.com> wrote:
> I'll give it ago first thing tomorrow, well after a cup of tea :)
>
> On 8/1/07, Rainer Jung <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <ja...@gmail.com>.
I'll give it ago first thing tomorrow, well after a cup of tea :)
On 8/1/07, Rainer Jung <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <ja...@gmail.com>.
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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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="Refresh"CONTENT="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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@kippdata.de> 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="Refresh"CONTENT="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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
>> 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 <ra...@kippdata.de> 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="Refresh"CONTENT="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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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="Refresh"CONTENT="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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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="Refresh"CONTENT="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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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 <be...@benshort.co.uk> 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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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 <ra...@kippdata.de> 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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Posted by ben short <be...@benshort.co.uk>.
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 <ra...@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat cluster serving ~50 lines of the page when a request hits
a stopped webapp for the first time
Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org