tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Tomcat cluster serving ~50 lines of the page when a request hits a stopped webapp for the first time
Date Wed, 01 Aug 2007 15:10:32 GMT
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 ...



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 <> 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
>>> -->
>>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>>> "">
>>> <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=">-->
>>> ..
>>> ..<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 <> 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:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message