[jcifs] More and more transport threads in blocking state

[Dev]

Michael B Allen <ioplex <at> gmail.com> writes:

> 
> On Tue, Aug 12, 2014 at 7:57 AM, Stefan Neis <stefan.neis <at> auteq.de> 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
> 



Hi Michael,

I am getting the below exception when I try to use JCIFS-1.3.17.jar.
 Please let me know what is the 
resolution. Also can you let me know what are the ports that
 JCIFS uses to connect to the destination 
server? Is it something if we try to open the ports from source
 to destination would help?

Thanks in advance.

osgi.wiring.package=*) -> [0]
jcifs.smb.SmbException: Failed to connect: 0.0.0.0(00)/10.12.212.41
jcifs.util.transport.TransportException: Connection timeout
        at jcifs.util.transport.Transport.connect(Transport.java:174)
        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.open0(SmbFile.java:972)
        at jcifs.smb.SmbFile.open(SmbFile.java:1006)
        at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:73)
        at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:65)
        at 

Thanks,
Dev