Re: More and more transport threads in blocking state

On Tue, Aug 12, 2014 at 7:57 AM, Stefan Neis <[email protected]> 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.

Hi Stefan,

I believe the "connection in error" condition will only occur if you
try to reuse the same transport after it just choked. Then, just in
case the server suddenly becomes alive at some point, it resets the
connection state. Thats why you then go back to "connect timed out". I
never really liked that behavior because it seems clumsey to ping-pong
between two different errors. But it's not obvious to me that anything
is logically wrong with this behavior. Think about it. If you try to
connect to a server and it chokes, why mindlessly try to connect to
the same server again? You should have some logic in your code that
catches the exception and just removes all targets on that server from
the list for the current scan.

So I would say that with some adjustment to your code as described
above and combined with using responseTimeout > connTimeout, that
should give you correct results.

If you're still not getting the desired result, please explain what
you think the correct results should be.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/