Re: And how about this mod_jk.log ?

[André Warnier <aw...@ice-sa.com>]

Hi.

Just to anyone who contributed ideas to the issue originally mentioned, 
thanks.

As a reminder, the problem was, on the one hand, entries like this one 
in the mod_jk logfile :

[Mon Jan 19 15:02:52 2009] [6802:4416] [info] 
ajp_process_callback::jk_ajp_common.c (1447): Writing to client aborted 
or client network problems
[Mon Jan 19 15:02:52 2009] [6802:4416] [info] 
ajp_service::jk_ajp_common.c (1846): (ajp13) request failed, because of 
client write error without recovery in send loop attempt=0
[Mon Jan 19 15:02:52 2009] [6802:4416] [info]  jk_handler::mod_jk.c 
(2190): Aborting connection for worker=ajp13

and on the other hand user's Internet Explorer displaying a not very 
helpful internal error page saying "This page cannot be displayed".

It turned out that what looked at first (to the customer) like a server 
or application problem, was in reality an intermediate network problem, 
with some in-between piece of equipment cutting off the browser/server 
TCP connection before the server had a chance to send the response
(and, thus, that the mod_jk log was very accurate).

Because the first part of this test had to be done by a non-specialist 
customer on a workstation to which I did not have access, I ended up 
writing a simple Perl script based on the integral LWP module, to better 
trace the problem at the workstation level.
The script is not very sophisticated, but was enough to demonstrate the 
problem and create a time-stamped trace allowing it to be cross-checked 
with the mod_jk log.  The script is very easy to use, on any platform 
that has perl installed (and that nowadays is not difficult to achieve, 
not intrusive, and easily cleaned up afterward if you so wish).  It 
works a bit like a URL -checker, but has some options better-adapted to 
what I needed.
You just feed it a text file containing some HTTP/HTTPS URLs to use for 
testing, and it will print useful time-stamped messages to STDOUT. It 
only gets verbose in case of error, which is generally what one wants.

You can download it from here, and feel free to use it and modify it as 
you please, under whichever free license you favor.

http://dev.dev.wissensbank.com/public/HTTPchecker.pl

"perl HTTPchecker.pl" will display the usage.

Also, if by any chance you did not know this much more sophisticated 
tool which comes automatically with the perl distributions, check out 
"lwp-request".

Re: And how about this mod_jk.log ?

[Rainer Jung <ra...@kippdata.de>]

On 06.02.2009 14:46, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> André Warnier wrote:
>> Because the first part of this test had to be done by a non-specialist
>> customer on a workstation to which I did not have access, I ended up
>> writing a simple Perl script based on the integral LWP module, to better
>> trace the problem at the workstation level.
>
> I'd just like to point out that there are two existing tools that may
> have helped you our a lot: wget (often installed be default on many
> Linuxes these days) and httping (which is not, but freely available and
> has a simple "make" compile strategy).

and curl ...

But André: thanks a lot for the feedback about the final resolution!

So we can still pretend client errors are not mod_jk's fault :))

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: And how about this mod_jk.log ?

[André Warnier <aw...@ice-sa.com>]

Chris,
> 
> I'd just like to point out that there are two existing tools that may
> have helped you our a lot: wget (often installed be default on many
> Linuxes these days) and httping (which is not, but freely available and
> has a simple "make" compile strategy).
> 
I thought about those, but did not use wget, ab, curl etc.. because
- the problem happened on users Windows workstations, and I wanted to 
test from there. Neither of the above are standard under Windows, some 
may be hard to find in Win32 binary version.
- neither wget or these other tools, I believe, allow by themselves to 
run the test on a series of URLs, in a loop, with a variable time-out
- I wasn't sure of the level of debugging information I'd get when there 
was a connection drop, without at the same time getting a lot of verbose 
stuff when no error was found
- the Windows "shell" under which I would have had to do something in 
order to wrap any of the above to do what I wanted is not exactly my 
preferred programming environment
- on the other hand, perl was already installed on the workstation and 
for things like that it is really great

And let anyone who hasn't ever re-invented a personal version of the 
wheel throw me the first stone.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: And how about this mod_jk.log ?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

André Warnier wrote:
> Because the first part of this test had to be done by a non-specialist
> customer on a workstation to which I did not have access, I ended up
> writing a simple Perl script based on the integral LWP module, to better
> trace the problem at the workstation level.

I'd just like to point out that there are two existing tools that may
have helped you our a lot: wget (often installed be default on many
Linuxes these days) and httping (which is not, but freely available and
has a simple "make" compile strategy).

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmMPx0ACgkQ9CaO5/Lv0PBEJQCdHlLSnx3tMBLVMTLmvfX4UkJG
6/0AoJs61rLhETYsuDV2CDE6yvSGhD1f
=YV3l
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org