tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: And how about this mod_jk.log ?
Date Wed, 28 Jan 2009 22:34:48 GMT
Hi André,

On 28.01.2009 19:15, André Warnier wrote:
> Caldarale, Charles R wrote:
>>> From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message