Bug 43621 - soTimeout not worked on channelNioSocket
Summary: soTimeout not worked on channelNioSocket
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 6.0.0
Hardware: All All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-14 17:14 UTC by william.barker
Modified: 2007-10-25 20:08 UTC (History)
0 users



Attachments
Patch to fix this problem (2.61 KB, patch)
2007-10-14 17:19 UTC, william.barker
Details | Diff
TC6 version of the patch (2.61 KB, patch)
2007-10-25 20:08 UTC, william.barker
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description william.barker 2007-10-14 17:14:51 UTC
I have configuared tomcat to use the NIO impl over AJP, here are the lines in
server.xml 
    <Connector address="127.0.0.1" port="0" 

               channelNioSocket.port="8009" 
               channelNioSocket.soTimeout="600000" 
               channelNioSocket.bufferSize="16384" 
               channelNioSocket.maxThreads="125" 
               channelNioSocket.minSpareThreads="10" 
               channelNioSocket.maxSpareThreads="50" 

               redirectPort="8443" protocol="AJP/1.3" 
               useBodyEncodingForURI="true" 
               /> 

(TC version 5.5.17) 
I had setted the soTimeout with 10 minutes, cause I notice such stages in
server status 

Stage Time B Sent B Recv Client VHost Request 
S 33280840 ms 359 KB 0 KB x.x.x.x 127.0.0.1 GET ... 

That shows several requests were blocking on reading request bodies for
hours. 

But unfortunately it dosen't worked for me, I am expecting a request should
only blocking mostly 10 minutes on read, after that a SocketTimeoutException
should raised. 

After digest the source code of ChannelNioSocket.java, I found that
ChannelNioSocket.SocketInputStream just wait infinitly if no data comes
while socket could not be detected closing 

        private void block(int len) throws IOException { 
            ... ... 
            if(!dataAvailable) { 
                blocking = true; 
                if(log.isDebugEnabled()) 
                    log.debug("Waiting for "+len+" bytes to be available"); 
                try{ 
                    wait(socketTimeout); 
                }catch(InterruptedException iex) { 
                    log.debug("Interrupted",iex); 
                } 
                blocking = false; 
            } 
            if(dataAvailable) { 
                dataAvailable = false; 
                if(fill(len) < 0) { 
                    isClosed = true; 
                } 
            } 
        } 

The socketTimeout parameter is not used to throw SocketTimeoutException,
actually it has no meaning. 

I even read the source for TC 6.0.13, the same as above. 

Should it be more precisely that throwing SocketTimeoutException on later
condiction test for (dataAvailable) is not true? 

In ChannelSocket implement, the problem is not exists,  it uses blocking
Socket.getInputStream, and it would throws SocketTimeoutException for socket
timeout while Socket.setSoTimeout was called

-- 
View this message in context: http://www.nabble.com/soTimeout-not-worked-on-
channelNioSocket-tf4586319.html#a13091614
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Comment 1 william.barker 2007-10-14 17:16:43 UTC
Actually, it is a more general problem where the NIO/AJP Connector doesn't 
handle Apache dropping the connection well at all.  Fortunately, this module 
is still marked as "Experimental".
Comment 2 william.barker 2007-10-14 17:19:57 UTC
Created attachment 20976 [details]
Patch to fix this problem

This should fix the Apache close, when TC can detect it.  In addition it also
handles the case of non-default connectionTimeouts (which really isn't
recommended for this Connector).
Comment 3 william.barker 2007-10-21 01:37:32 UTC
Patch applied to TC 5.5, so changing version to 6.0 to apply the patch there 
as well.
Comment 4 william.barker 2007-10-25 20:08:11 UTC
Created attachment 21047 [details]
TC6 version of the patch

No functional change, but fixes packaging from 5.5 (which I forgot about)
Comment 5 william.barker 2007-10-25 20:08:54 UTC
This is now fixed in TC 5.5 and 6.0 with the patches attached.