You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@eng.sun.com on 2000/09/01 00:08:40 UTC

Re: Tomcat 3.2 beta3? problem with mod_jk

> There is currently a setSoLinger(true,100) call in Apj12ConnectionHandler.  I can try making it longer to see if it has an impact.

I don't think it'll help...



> Unfortunately, until now, I've only read about sockets.  I had not actually played with them.  During the debugging session last night, I never saw any of the response when recv() returned -1, i.e. the -1 always occurred on the first attempt to get response bytes.  When recv() didn't return -1, it either got the response in one piece of 337 bytes, or two pieces of 207 and 130 bytes.

Yes, but my assertion is that the -1 you get is because of the signal sent by the other
side closing the connection.




> Also, from my debugging session, I am not convinced that mod_jserv doesn't fail due to design.  It may be just luck.

It's not luck - they avoid this by letting Apache deal with the problem. I'll try to find how it
works on Apache - and cut&paste some code :-).


> The Windows documentation I looked at said to use the equivalent of the shutdownInput() and shutdownOutput() as part of closing a socket.  Unfortunately, these are only available in JDK 1.3.  I'll keep my fingers crossed that the error on the Java side doesn't render the queued output undeliverable, requiring the Java side be "fixed".

I don't think so.
We can fix this by adding a confirmation before closing the socket or not closing the
socket at all ( but that's already AJP13 :-)
BTW, the problem shouldn't occur with AJP13.

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