[jcifs] Re: SmbException in jcifs-1.2.7

[Michael B Allen]

On Thu, 5 Jan 2006 10:04:14 +0000 (UTC)
Rainer Buss <rainer.buss at rbconsult.de> wrote:

> The machine serving the remote directories, we are accessing, is
> always up, but sometimes there seem to be network problems
> or there may be problems with concurrent accesses ?

JCIFS is specifically designed for "concurrent access". But if
your network is flakey, increase your loglevel to 2 (should be ok in
production) and see if you're getting any timeouts. If so you might want
to look into the responseTimeout property.

> Could you please answer the following questions:
> 
> Is each instantiation of SmbFile a new (system-) mount in  jcifs ?

No. Mounts that connect to the same share are shared. Sessions that use
the same creds are shared. Transports to the same server are shared. But
the ssnLimit property limits the number of sessions on a transport. For
example if ssnLimit is set to 1 a new transport (and thus session and
thus mount) will be created for each SmbFile.

> Is this (system-)mount closed after life cycle of SmbFile instance ?

A mount is closed when the underlying session is closed. A session is
closed when the underlying transport is closed. A transport is closed
after no activity for soTimeout milliseconds (default 15000) or if a
transport error occurs.

> Is the number of parallel mounts on the same remote directory a problem ?

No. Or at least it should not be. There is a known deadlock caused when
a session tries to logoff at the same time one is trying to setup but
AFAIK only one user has been able to trigger it using a test environment
designed to stress the system.

> When we create a global SmbFile - instance for a directory, is
> directory.list() actual for each access or is there a delay.

I don't know what you mean. There should be no "delay". If the directory
is large (e.g. 15000 items) it could talk a while depending on network
conditions [1].

Mike

[1] One thing that greatly slows performance of JCIFS is attribute
expiration. If for example you list a large directory over a slow network
and it takes longer than attExpirationPeriod milliseconds (default
5000), querying attributes like getLength(), exists(), isDirectory(),
etc will cause the client to re-communicate with the server. Setting
a high attrExpirationPeriod can increase performance several orders of
magnitude in certain conditions.