tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: And how about this mod_jk.log ?
Date Wed, 28 Jan 2009 18:15:56 GMT
Caldarale, Charles R wrote:
>> From: André Warnier []
>> 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.
The flow is as follows :
Windows/IE6 -> Apache2.2 -> mod_jk1.2.28 -> Tomcat5.5 -> database app.
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.
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.

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 

Any tip on something else, easy to install and run, which would be 
better suited to what I need ?

>> 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:
For additional commands, e-mail:

View raw message