AgNO3 / jcifs-ng

A cleaned-up and improved version of the jCIFS library
GNU Lesser General Public License v2.1
318 stars 103 forks source link

jcifs.smb.SmbException: Failed to acquire credits in time after upgrade to jcifs-ng 2.0.8 (from 1.5.3) #132

Open johannes-martin opened 5 years ago

johannes-martin commented 5 years ago

I upgraded a couple of programs from jcifs-ng 1.5.3 to 2.0.8.

The clients now connect using SMBv2 (using jcifs.smb.client.disableSMB1=true) and usually work fine.

In some cases they fail with the above mentioned exception when trying to open an input stream for a file or when trying to rename a file. In all cases, it was previously (in the same VM) possible to obtain input streams for other SMB files without problems.

When the client runs ok, I see a number of messages like "File handle was not properly closed: FileHandle <path & name of the file>".

The clients close any input streams obtained. I reviewed the source for SmbFileInputStream and saw that its close() method only closes the SMB files for "unshared" input streams. I failed to find any code that actually returns an input stream in "unshared" mode.

Questions:

johannes-martin commented 5 years ago

It looks like explicitely closing the files after closing the input streams does not solve the problem.

johannes-martin commented 5 years ago

Further note: it looks like - even if I explicitely close the files - they do not actually get closed. An attempt to move a previously opened file on the command line while the Java program is still running fails saying that the resource is busy.

mbechler commented 5 years ago

Sorry for the delay.

It is no longer necessary to close the SmbFile in regular mode of operation (some info at https://github.com/AgNO3/jcifs-ng#jcifs-ng-16-unreleased). The "unshared" mode is only for specific situations in strictResourceLifecycle mode (which I would not recommend to use as the benefits are minimal).

However, now you have to make absolutely sure that you properly close Input and OutputStreams, RandomAccessFile, iterators and other returned handles. My best guess would be that you are missing a close call somewhere.

col-panic commented 3 years ago

I recently encountered this failure, and the stacktrace led me to SmbFile[] files = SmbFile.listFiles where I did not call close on the returned arrays single SmbFile objects. I'm not yet sure that this may have been the cause, but it seems like a valid reason.