You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2007/08/01 17:10:32 UTC
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 <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 <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