Rainer,
I setup a test httpd + loadbalancer with jk 1.2.24 and could reproduce
the problem over and over again. Then I patched the source and have
been unable to reproduce the problem with the patched mod_jk.so.
So the patch looks good.
Regards
Ben
On 8/1/07, ben short [EMAIL PROTECTED]
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,
Sure for stable operation, but what if the machine reboots, tomcat
starts up and your webapp doesn't for some reason. This situation
could occur then.
Many thanks for your help with this one.
Regards
Ben
On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote:
Hi Ben,
I think I understand the
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
I'll give it ago first thing tomorrow, well after a cup of tea :)
On 8/1/07, Rainer Jung [EMAIL PROTECTED] wrote:
hi Ben,
could you try the following patch for 1.2.24:
http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch
I guess you can build the module yourself (it's
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
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
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
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
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
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
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:
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
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
Hi Rainer,
By shutdown I mean I have clicked the 'stop' link on the tomcat manager page.
Im also using session replication between the two tomcats.
I have just tried turning off firefoxes cache and I see the same result.
On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote:
Hi Ben,
I don't know
So how does setting sticky sessions to true and the default value for
the Load Balancing Directive 'method' (defaults to request) interact
then?
On 7/30/07, Rainer Jung [EMAIL PROTECTED] wrote:
Apart from all the other things I wrote: don't turn off session
stickyness, even if you use
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
17 matches
Mail list logo
