[jcifs] More and more transport threads in blocking state

[André Warnier]

Stefan Neis wrote:
> Hello Mike,
> 
> disabling DFS makes no difference. If I use the setting with
> responseTimeout > connTimeout the threads do not block themselves
> anymore, but then I got another anomaly.
> 
> The first call of exists() returns after a delay with the result of an
> exception like before and the transport thread terminates.
> 
> jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.100.77
> jcifs.util.transport.TransportException
> java.net.SocketTimeoutException: connect timed out
> 	at java.net.DualStackPlainSocketImpl.waitForConnect(Native
> Method)
> 	at java.net.DualStackPlainSocketImpl.socketConnect(Unknown
> Source)
> 	at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown
> Source)
> 	at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> 	at java.net.PlainSocketImpl.connect(Unknown Source)
> 	at java.net.SocksSocketImpl.connect(Unknown Source)
> 	at java.net.Socket.connect(Unknown Source)
> 	at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:264)
> 	at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)
> 	at jcifs.util.transport.Transport.run(Transport.java:241)
> 	at java.lang.Thread.run(Unknown Source)
> 
> 	at jcifs.util.transport.Transport.run(Transport.java:258)
> 	at java.lang.Thread.run(Unknown Source)
> 
> But the second call in the loop throws a slightly different exception
> and returns immediately without delay and with no transport thread
> created.
> 
> jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.100.77
> jcifs.util.transport.TransportException: Connection in error
> jcifs.util.transport.TransportException
> java.net.SocketTimeoutException: connect timed out
> 	at java.net.DualStackPlainSocketImpl.waitForConnect(Native
> Method)
> 	at java.net.DualStackPlainSocketImpl.socketConnect(Unknown
> Source)
> 	at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown
> Source)
> 	at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> 	at java.net.PlainSocketImpl.connect(Unknown Source)
> 	at java.net.SocksSocketImpl.connect(Unknown Source)
> 	at java.net.Socket.connect(Unknown Source)
> 	at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:264)
> 	at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)
> 	at jcifs.util.transport.Transport.run(Transport.java:241)
> 	at java.lang.Thread.run(Unknown Source)
> 
> 	at jcifs.util.transport.Transport.run(Transport.java:258)
> 	at java.lang.Thread.run(Unknown Source)
> 
> 	at jcifs.util.transport.Transport.connect(Transport.java:154)
> 	at jcifs.smb.SmbTransport.connect(SmbTransport.java:307)
> 	at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
> 	at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
> 	at jcifs.smb.SmbFile.connect(SmbFile.java:954)
> 	at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
> 	at jcifs.smb.SmbFile.exists(SmbFile.java:1415)
> 	...
> 
> The third call behaves like the first and the fourth like the second and
> so on.
> 

I have no idea of the code underlying this, but the above makes it look as if the second 
attempt was trying to re-use the same outgoing socket as the first, and that socket was 
still under the initial error condition.  So the second call returns right away, without 
even attempting a connection.
And to explain the behaviour of the 3rd attempt, maybe a look at the TCP/IP state diagram 
in the case of a client connection timeout would provide a clue ?
(it may still be using the same socket, but by that time the error status is cleared ?)