Yes, I know.
Originally I wrote that because of the observed Headers with LiveHTTPHeaders
in Mozilla. I didn't realize that Transfer-Encoding is an Hop-To-Hop header
which was stripped by our proxy-server. Later during snooping I also noticed
that this header wasn't send by Tomcat through the AJP
I requested this URL a few seconds ago, using
curl -D - http://www.kpn.com/kpn/show/
and it had the header
Transfer-Encoding: chunked
set. This somehow contradicts your first mail.
Regards,
Rainer
Henk Fictorie wrote:
In the original posting I mentioned a monitoring tool which was triggere
In the original posting I mentioned a monitoring tool which was triggered by
this behaviour. This monitoring tool has several machines watching our
website. I have been snooping the port 80 requests from these machines for
the last two days, but they haven't triggered the 300 sec. delay. I will tr
Ok, I did the snooping and analyzing.
What happens is at follows:
- mod_jk sends request
- tomcat responds within a fraction of a second
- tomcat ends with sending an 'end-response' message with reuseport set to
TRUE
- exacat 5 minutes (300 seconds) later mod_jk report a client write error
(jk_aj
Hi Henk,
I'll try to find the reason. Would it be easy for you to repeat the test
with a very raw client? If the URL is easy you could e.g. telnet to the
APACHE port and simply write
GET /myurlRETURN
RETURN
I'm asking for that, because the client write error sounds a little
strange to me, and I
Hi Henk, do you have a simple app to reproduce the problem?
Rainer Jung schrieb:
> Hi Henk,
>
> I'll try to find the reason. Would it be easy for you to repeat the test
> with a very raw client? If the URL is easy you could e.g. telnet to the
> APACHE port and simply write
>
> GET /myurlRETURN
>
Henk Fictorie wrote:
The problem reproduces itself automagically, but not at the moment I
want.
Well ...
I think I will snoop the traffic with Tomcat during one hour or so (appr. 1
Gig of data, on a different filesystem). Using editcap to divide the
capturefile in reasonable sized parts.
The problem reproduces itself automagically, but not at the moment I
want.
I think I will snoop the traffic with Tomcat during one hour or so (appr. 1
Gig of data, on a different filesystem). Using editcap to divide the
capturefile in reasonable sized parts. Examining the logfile will reveal a
Can you reproduce the problem? This would help a lot.
Henk Fictorie schrieb:
> Solutions?:
> - will adding 'JkOptions +FlushPackets' to the apache config help?
If the pain is big enough for you, you could try, but it will also come
with a performance penalty.
> - can I somehow disable sending th
