Server refuses new credits after a certain time

[guillaume-alvarez]

Hello,

I am confronted to a NAS that rejects credits requests after a certain time (about 2h40 when downloading 80k files).
Then I get the 'Failed to acquire credits in time' error at every following request.

When restarting my whole connection it performs better and can again download for about 2h40/80k files.

I would like my connection to be more resilient:

• is it expected that JCIFS does not disconnect automatically when it fails to acquire credits?
• what is the best way to manually disconnect?
  • I already crawled lots of files in sub-directories that I have not yet downloaded and I'd like not to recreate the context and re-crawl them.
  • I'm thinking about calling SmbFile.getContext().close() as it looks like it recovers from this, would it be an issue?

Thanks!

[mbechler]

Originally I did not consider this a hard error, leading to a disconnect, as there is a chance that - if there are still inflight requests - such a condition may be legitimately caused by client code using exzessive parallelism. However, I tend to agree that for most people this will be a non-recoverable error. We could probably even distinguish the two cases.

Still, would be interesting to figure out what causes the credit issue in the first place.

The least invasive would be something along the lines:

((SmbTreeHandleInternal)file.getTreeHandle())
.getSession().unwrap(SmbSessionInternal.class)
.getTransport().unwrap(SmbTransportInternal.class)
.disconnect(true, true);

This uses internal APIs for which I don't want provide long term stability guarantees, but I don't see why these specific calls should change anytime soon.

Calling SmbFile.getContext().getTransportPool().close() - compared to SmbFile.getContext().close() - would probably be more future proof. However, depending on your usage pattern this might also forcibly close other connnections besides the one you are interested in.

[guillaume-alvarez]

Thanks for this detailed answer!

The credits issue is indeed caused by excessive parallelism wrt to the server limitations (even 4 threads is too much).

In that case I would like to be able to detect it, then reduce the number of parallel threads in my client and continue downloading. However if I only catch the SmbException notifying of the credits timeout then reduce the number of threads I still get the same issue. If I open a new connection it works.

It may well be a server issue. The NAS is a consumer-grade one.

However, I tend to agree that for most people this will be a non-recoverable error. We could probably even distinguish the two cases.

Maybe add a configuration option for this?
It is better to fail with a clear error by default than keeping a zombie process alive and be under the illusion it works.