[jcifs] JCIFS timeouts on windows
Michael B Allen
mba2000 at ioplex.com
Fri Mar 10 05:26:26 GMT 2006
On Thu, 9 Mar 2006 22:02:18 +0000 (UTC)
Justin Greene <97r5-4rku at spamex.com> wrote:
> We have been using JCIFS for some time to communicate between our Java apps
> (running on windows) and Windows fileserver. We constantly receive timeouts
> reading data from the network in the form:
> Caused by: jcifs.smb.SmbException:
> jcifs.util.transport.TransportException: Transport1[DATA01-
> NYC<20>/192.168.0.66:445] timedout waiting for response to
> [command=SMB_COM_TRANSACTION2,received=false,errorCode=The operation completed
> at jcifs.smb.SmbTransport.send(SmbTransport.java:533)
> at jcifs.smb.SmbSession.send(SmbSession.java:228)
> at jcifs.smb.SmbTree.send(SmbTree.java:102)
> at jcifs.smb.SmbFile.send(SmbFile.java:688)
> at jcifs.smb.SmbFile.queryPath(SmbFile.java:1196)
> at jcifs.smb.SmbFile.exists(SmbFile.java:1250)
> at jcifs.smb.SmbFile.isDirectory(SmbFile.java:1323)
> This timeout even occurs connecting to shares on the local machine, so it is
> not the network. I have increased the timeout to 60 seconds (-
> Djcifs.smb.client.responseTimeout=60000) and it still occurs. Any advice on
> how to troubleshoot this would be greatly appreciated as it is really becoming
> a thorn. There is some reference in the docs to increasing the jcifs log level
> but I cannot seem to figure out to where it logs. Any help would be
How frequently does it happen?
Did it just start happening or has the problem occured since you started
Once it happends, does it occur for all subsequent requests to that
server or is it just that one request that chokes?
You're going to have to present more information. You didn't even tell
us what version you're using.
Try upgrading to the latest version.
Try setting the timeout to something really huge just to make SURE it's
not making progress. Also, I think when you increase responseTimeout,
you need to increase soTimeout as well.
Logging is to System.err by default. I think you can do something
like jcifs.util.LogStream.setInstance( new jcifs.util.LogStream( new
FileOutputStream( "c:\temp\jcifs.log" ))) but it must be called before
any jCIFS classes are loaded (ie. in main).
Another good thing to do would be to get a packet capture of the traffic
 and check to make sure the response is really not being received. If
the response is being received then it's a bug in the version of jcifs
you're using. If the response is not being received then ...
That should keep you busy for a while :->
More information about the jcifs