[jcifs] JCIFS reconnect issue

[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
 >
 >
 >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) 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" 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
 >
 >-- 
 >Michael B Allen
 >Java Active Directory Integration
 >http://www.ioplex.com/
 >