Hi André,
On 28.01.2009 19:15, André Warnier wrote:
Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Subject: And how about this mod_jk.log ?
I see mod_jk messages as listed below (from mod_jk to client, and from
mod_jk to Tomcat).
Any chance of getting network traces for both the httpd-Tomcat and
httpd-client connections? Might shed some light on what's really going
on.
Well..
The flow is as follows :
Request:
Windows/IE6 -> Apache2.2 -> mod_jk1.2.28 -> Tomcat5.5 -> database app.
Response:
Windows/IE6 <- Apache2.2 <- mod_jk1.2.28 <- Tomcat5.5 <- database app.
Apache, mod_jk and Tomcat run on a single Linux host.
I do have remote access to the host, but only through a Citrix
firewall/console where my only accesses are a putty client (SSH) and a
kind of Norton Commander file explorer.
Putty ssh access to the Linux system is great :)
I do not have remote access at all to the workstations.
Whatever I could ask the customer to do at their end would have to be
relatively simple.
Simple will not necessarily help for a complex problem.
So what are my simplest options ?
My plan right now would be to run a simple "HTTP-getter" program on a
workstation, to see if that one confirms what IE is saying.
My first candidate is "ab", which belongs to the standard Apache MSI
installer too, and which I could ask to customer to install, then
disable (http), then run ab in a command window, re-directing the output
to a file.
I have tried that locally and it seems to work. Unfortunately, on my own
network I have trouble reproducing the error that the customer is
seeing, everything works fine here unfortunately. So I don't know how
much error information ab provides when there is actually a problem.
It is not really a debugging tool, more like a tool to measure server
performance.
Any tip on something else, easy to install and run, which would be
better suited to what I need ?
Although I'm mainly repeating what Chuck already said, I'll paste my
original answer here, which unfortunately never left my Drafts mailbox :(
I would sniff network traffic. Since there is a chance that an active
network component is involved, first sniff directly in front of Apache.
Use the JK logs to get the timestamps fo the write error. Try to find
the corresponding packets in the sniff and then look at the
corresponding TCP connection and see, whether the client actually reset
or closed the connection before mod_jk ran into the error. If so, move
your sniffer closer to the clinet in terms of network components until
you finally reach the internet router.
It is some work, but if the problem is important it will allow you to
narrow down the root cause.
Sniffing here means using tcpdump on the linux system. Don't retrieve
life decoded data, instead use tcpdump with "-s 0" and "-r filename" to
dump the full packets to a file (on a file system with enough space) and
analyze the data later. Of course you would also add a port filter
expression for your HTTP(S) port(s). See "man tcpdump".
I wish you success, and if your sniffer analysis indicates any JK or
httpd problem, come back here.
Regards,
Rainer
The browser is IE6, and often returns a "This page cannot be
displayed" ("friendly IE error message", which unfortunately
cannot be turned off by the users, settings locked).
It is possible to defeat the IE silliness by generating a relatively
long error page (I forget what the threshold is, but it's discussed on
this mailing list occasionally), although this may well be just a
timeout so it wouldn't matter.
Yes, I thought of that, and 1025 bytes should be enough. But I thought
of that too..: if there is never an error page sent by the server (which
looks likely here, since it can't even send a normal response), then the
IE error page is IE's internal one anyway. For once it is not hiding the
useful server information, and being friendly in a way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
