JCIFS: file retrieval is too slow to be usable

Question

I was just testing JCIFS for accessing Windows shares. It is very slow to the point of being completely unusable.

import jcifs.smb.*;

class First {
    publ         


        

Answer 1

I found somewhere that SmbFileInputStream doesn't do its own buffering and hence the reason for being slow. Wrapping SmbFileInputStream in a BufferedInputStream solved the problem.

 SmbFile sFile = new SmbFile(path, authentication);

 BufferedInputStream buf = new BufferedInputStream(new SmbFileInputStream(sFile));

Answer 2

In my own case, pushing files TO a Windows share via JCIFS was too slow to be usable.

The solution turned out to be defining the property

-Djcifs.resolveOrder=DNS

The default inclusion of BCAST -- broadcasting a NetBIOS name query to 255.255.255.255 -- was needlessly resulting in a lengthy delay. (Link above de-framed from the top-level API docs.)

Answer 3

If you can rely on "something else" to mount the share as a local directory for you, then reading files in the mounted share in Java should be portable.

Even if this is not a real solution, it would be worth trying this to see if you get a faster read rate. A significantly faster read rate might change your mind about the relative importance of portability. And if you don't get a significant speedup, then you'll know that JCIFS is not to blame ...

Answer 4

I know this is an old question, but for anyone else who has tried the other solutions to no avail:

In my case, I was able to track the slowdown to jcifs' heavy use of SecureRandom, which blocks if /dev/random reports insufficient entropy.

Installing rng-tools and configuring and enabling rngd brought performance up to acceptable levels.

You can check the available entropy (on RHEL at least) with the following command:

cat /proc/sys/kernel/random/entropy_avail

Answer 5

What I noticed is that jCIFS does "something" (afair jcifs.smb.SmbTransport.checkStatus(..)) for every chunk it reads - i.e. for each chunk that is read into the buffer. That means using a BufferedInputStream might really speed things up, but the real problem still exists. It only doesn't occur as often as before and therefore has a lower impact on the overall time ..

It helps a lot to set "jcifs.util.loglevel=3" and have a look what's really wrong!

In my case I had to set "jcifs.smb.client.dfs.disabled=false" in the end, as "jcifs.resolveOrder=DNS" didn't help..

Answer 6

The solution added by @Xolve0 worked for me as well. The buffer issue in the SmbFileInput is also present when trying to write files. I used the same BufferedInputStream(new SmbFileInputStream(sFile)) to make the time execution decrease from 90secs to less than a second for a plain text file.

A quick way to identify this specific issue would be to track the time between the opening of the JCIFS path and the write of the file itself.