Re: JCIFS reconnect issue

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

On Thu, Feb 12, 2015 at 4:16 AM, M. D. <[email protected]> wrote:
>  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.
>
>
>
>  >-------- =D0=9E=D1=80=D0=B8=D0=B3=D0=B8=D0=BD=D0=B0=D0=BB=D0=BD=D0=BE =
=D0=BF=D0=B8=D1=81=D0=BC=D0=BE --------
>  >=D0=9E=D1=82:  Michael B Allen
>  >=D0=9E=D1=82=D0=BD=D0=BE=D1=81=D0=BD=D0=BE: Re: [jcifs] JCIFS reconnect=
 issue
>  >=D0=94=D0=BE:  M. D.
>  >=D0=98=D0=B7=D0=BF=D1=80=D0=B0=D1=82=D0=B5=D0=BD=D0=BE =D0=BD=D0=B0: =
=D0=92=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 2014, =D0=9E=D0=BA=D1=82=D0=BE=
=D0=BC=D0=B2=D1=80=D0=B8 7 03:31:37 EEST
>  >
>  >
>  >On Fri, Oct 3, 2014 at 2:23 AM, M. D.  wrote:
>  >>  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) an=
d 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)
>  >
>  >> Is there any chance that JCIFS cached a &quot;fail to connect&quot; r=
esponse the first few times when the machine was actually down and then ref=
used 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 &quot;in error&quot; 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