tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <>
Subject RE: Tomcat 3.2 beta3? problem with mod_jk
Date Wed, 06 Sep 2000 21:39:15 GMT
I don't see this as a priority.  It is still an error even if the wrong result code is returned.

With AJP13, do you know what is supposed to happen with the POST's unread content in this

I get a number of failures in test-tomcat.xml using AJP13.  Does it have known problems in
Tomcat 3.2, or is it supposed to be ready for use?  I'll try to investigate further.


-----Original Message-----
From: []
Sent: Wednesday, September 06, 2000 4:52 PM
Subject: Re: Tomcat 3.2 beta3? problem with mod_jk

Hi Larry,

Well, at least we don't have a regression.

I think we do have a solution - mod_jk with AJP13. Since it
keeps the connection alive and have bi-directional support
it can negociate a clean shutdown.

I think fixing ajp12 is far more complex than making sure
ajp13 is stable and works fine. Since the bug was probably
present in 3.0/3.1, and affects only special cases I would
vote to leave it as it is.

If this becomes a priority we can hack something in - like
 a JNI method to do the right shutdown ( and use it instead
of close() - AFAIK you can access the file ID and use
it in a native method).


> I finally managed to try your suggestion.  Retrying the read() after the WSAESHUTDOWN
was not successful.
> I also did further tests with mod_jk.dll and ApacheModuleJServ.dll.  It appears that
maybe ApacheModuleJServ.dll does a better job of delivering the content to Tomcat, i.e. the
content is either in the buffer or "available" when close is called.  It doesn't arrive while
the close() is occurring, at least when the content is short enough,  However, if I increase
the content length beyond 8K, then ApacheModuleJServ.dll will show the 500 error like mod_jk.dll.
> According to the Microsoft documentation, there should be a handshake using shutdown()
to insure content is delivered before closing the socket.  This currently doesn't occur at
least from the Tomcat side of the socket.  Maybe Microsoft could have implemented it better,
but it appears that the arrival of input at the wrong time in socket closure can abort the
delivery of output.
> For pre-JDK 1.3, perhaps Ajp12ConnectionHandler.processConnection() could read the content
up to some limit (8k maybe), skip any currently available data, then close the socket.  By
then we can hope the error response has been delivered and closing with a WSAESHUTDOWN error
won't cause a problem.  For JDK 1.3, I think the shutdownInput() and shutdownOutput() should
be used.
> Is this too much of a hack?  Suggestions when you get a chance.  Thanks.
> Larry
> -----Original Message-----
> From: []
> Sent: Thursday, August 31, 2000 6:09 PM
> To:
> Subject: Re: Tomcat 3.2 beta3? problem with mod_jk
> Can you try one more trick:
> - if read() returns -1
>        1. print errno ( for debug )
>        2. if errno == EINTR  ( that should be the case on unix)  or WSASHUTDOWN - go
back and read again.
> I'll try to help more next week, I have to finish some work.
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message