[jcifs] JCIFS reconnect issue

Michael B Allen

2015-02-15 03:38:52 UTC

Hi M.D.

The "questionable logic" is the clause that "catches" the exception in
jcifs.util.transport.Transport.connect() and puts the transport "in
error".

The logic is a crude way to slow down code that is incessantly calling
JCIFS routines that are failing such when something is trying to crawl
files on a server that is suddenly not available.

I think the "fix" would be to add an onException method or a callback
somewhere that gets called from jcifs.util.transport.Transport.run()
if doConnect fails so that the caller can decide what to do. There are
exceptions that should necessitate that the caller stop (server down)
and there are exceptions that they might ignore (access denied). So
there is a little bit of a dilemma as to what to do.

You are welcome to try to provide a fix and submit it. But to be
honest, it would probably not be really integrated or even reviewed
properly for months. Things just don't move that fast around here.

Mike

Post by M. D.
Hello Mike,
Thanks for the explanation.
Can you point me to the "questionable logic" that you were talking about? Which class implements this logic? I might be able to provide a fix if you could be a little more specific to what I should look for.
Thanks in advance!
Best regards,
M.D.

-------- Оригинално писмо --------
От: Michael B Allen
Относно: Re: [jcifs] JCIFS reconnect issue
До: M. D.
Изпратено на: Вторник, 2014, Октомври 7 03:31:37 EEST

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)
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