[jcifs] JCIFS reconnect issue

[M. D.]

Hello,

I have a question about jcifs-1.3.17.

Does JCIFS perform any kind of address caching? Because sometimes I'm experiencing an issue which after successful polling of a shared directory I lose connectivity to the remote machine (because it is down or moved) and then when the connectivity is up again JCIFS fails to reconnect:

cifs.smb.SmbException: Failed to connect: sf5/10.4.4.51
jcifs.util.transport.TransportException: Connection in error
jcifs.util.transport.TransportException
java.io.IOException: Failed to establish session with sf5/10.4.4.51
at jcifs.smb.SmbTransport.ssn139(SmbTransport.java:239)
at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:249)
at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)
at jcifs.util.transport.Transport.run(Transport.java:241)
at java.lang.Thread.run(Thread.java:662)

at jcifs.util.transport.Transport.run(Transport.java:258)
at java.lang.Thread.run(Thread.java:662)

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.resolveDfs(SmbFile.java:669)
at jcifs.smb.SmbFile.send(SmbFile.java:773)
at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1986)
at jcifs.smb.SmbFile.doEnum(SmbFile.java:1738)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1704)

Is there any chance that JCIFS cached a "fail to connect" response the first few times when the machine was actually down and then refused to connect later when the connectivity is UP?

Best regards,
M.D.

[Michael B Allen]

Post by M. D.
Hello,
I have a question about jcifs-1.3.17.
cifs.smb.SmbException: Failed to connect: sf5/10.4.4.51
jcifs.util.transport.TransportException: Connection in error
jcifs.util.transport.TransportException
java.io.IOException: Failed to establish session with sf5/10.4.4.51
at jcifs.smb.SmbTransport.ssn139(SmbTransport.java:239)
at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:249)
at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)

<snip>

Post by M. D.
Is there any chance that JCIFS cached a "fail to connect" response the first few times when the machine was actually down and then refused to connect later when the connectivity is UP?

Hi M.D.,

Yes, JCIFS reuses connections so there is some questionable logic that
tries to slow down code that tries to incessantly query some target
that's just down.

I think if you just don't poll more frequently than
jcifs.smb.client.connTimeout (default is 35 seconds) the transport
should timeout and clear the "in error" state. So I would not poll
more frequently than a 60 or so (although its probably only not
obnoxious to poll more frequently than 5 minutes or so). And bear in
mind that transports are shared so if you have multiple threads
processing a big list of objects, each time you touch one on a
particular server that resets the timeout. So you have to completely
stop doing anything for > 35 seconds to ensure that the connection
closes and that you get a nice new fresh connection.

Also, make that sure you create a new SmbFile object for each
operation. SmbFiles do cache information like file attributes. So you
need to create a new SmbFile object for each operation to get the
freshest possible information.

Mike