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 Thu, 31 Aug 2000 22:08:40 GMT
> 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.


View raw message