tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Tomcat 3.2 beta3? problem with mod_jk
Date Wed, 30 Aug 2000 17:55:51 GMT
Hi Larry,

AFAIK mod_ajp12 should work in exactly the same way as mod_jserv.

One possible explanation is that tomcat is closing the connection without
reading the full request body, and that generates an abort signal that is
received by mod_jk before the actual response data.


- mod_jk sends request, request body
- tomcat reads request, request body ( incomplete - either because mod_jk
sent too much data or content_length is too small )
- tomcat executes the request, sends back the response ( you can test this
easily by adding few printfs)
- apache starts receiving data.
- tomcat closes the connection. Because some data is still in the input
buffer a TCP abort will be send. 
- the ABRT signal is received by mod_jk. It will generate an error ( and
it is out-of-band AFAIK, so the error will happen before the data is read
from the buffer).

This would explain the random behavior - mod_jk may receive the abort
packet after it read the previous data packets or not.

I'm not sure this is the real reason ( and some of the tcp terms may be

I would guess this doesn't happen on mod_jserv because it is using an
apache method that may have a workaround for that.

Let me know if you can verify that tomcat is sending the data.
( a not-so-simple way to test this is the case is to use tcpdump or 
something equivalent )

I'll try to reproduce it on linux ( I still don't know how to run on
windows :-)


On Wed, 30 Aug 2000, Larry Isaacs wrote:

> Hi,
> In the "tomcat_32" branch, I have updated the test-tomcat.xml so that it should execute
without error.  I get error free execution on Windows NT 4.0 (SP5) and Windows 98SE when testing
Tomcat 3.2 directly.  Using the new "client-apache" target, I get error free execution with
Apache/ApacheModuleJServ.dll.  (Note: I start Apache and Tomcat separately from running the
> However, with Apache/mod_jk.dll (3.2b2 version and new locally compiled version), I typically
get failures on the first three tests of the "post" target.  In each failure, the return code
is 500 instead of the one expected.  It doesn't happen all the time, and I have never seen
it happen when the first "post" test is run separately in its own target.
> After modifying server.xml (no other changes were made) to capture the "tomcat.log",
I find for the first "post" failure that Tomcat logged 404 as the return response, which is
the correct response.
> After building a debug version of mod_jk.dll from "tomcat_32" sources, I find that as
part of the handling for ajpv12_handle_response() in jk_ajp12_worker.c, the fill_buffer()
routine in jk_socketbug.c is eventually called.  In the fill_buffer() routine, the recv()
function call is returning -1.  The Win32 WSAGetLastError() function returns that the error
was WSAWASSHUTDOWN, which implies that shutdown() was called for the socket.
> It would be a help to me if someone could provide some more information about the architecture
here and what should be happening.  I don't see a call to shutdown() in jk_ajp12_worker.c.
 Can a "shutdown" be caused from the Tomcat side?  Any advice would be appreciated.
> I'm not sure if this problem is serious enough to hold up Tomcat 3.2.  Since mod_jk is
being recommended over JServ, it would be good to find out if this is a quirk of test-tomcat.xml
or something more general.
> I'd be curious if anyone else can duplicate this problem, and for that matter, how the
new test-tomcat.xml does on non-Windows platforms.  Thanks.
> Cheers,
> Larry
> __________
> Larry Isaacs		
> SAS Institute Inc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message