Re: JCIFS reconnect issue

 Hello Mike,

Thanks for the explanation.=20

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 y=
ou 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=20
 >=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. =20
 >=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 directo=
ry 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)
 >
 >> Is there any chance that JCIFS cached a "fail to connect" r=
esponse the first few times when the machine was actually down and then r=
efused 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
 >
 >--=20
 >Michael B Allen
 >Java Active Directory Integration
 >http://www.ioplex.com/
 >