[jcifs] holding open a connection

[Michael B Allen]

On Sun, 13 Jan 2002 01:51:06 -0500
Bruce Altner <baltner at hq.nasa.gov> wrote:

> Mike:
> 
> I continue to be amazed at the level of help you provide to me and others 
> on this list. Thanks for the detailed writeup, which addressed the very 
> issues I was concerned about. It seems that the 
> SmbTransport/SmbSession/SmbTrees provides just what I needed, although the 

Gee, thanks :-)

> 15 seconds timeout seems awfully short. What would the effect of increasing 
> this to, say, 10 minutes, do?
> Is that an eternity in this context?

That sounds good. I would advise against using 0 (forever) though.

> As for the possible problems you describe with servlets, I think that we 
> are OK. There is only one instance ever created of a given servlet..as 
> different users come in new threads are created or are taken from a thread 
> pool to handle their requests. But this brings up a related question, 
> then...is jCIFS thread safe? Will I need to synchronize jCIFS method calls?

The client is thread safe. In fact it multiplexes IO very finely (e.g. two
requests can go out and the second response can be received before the
first) but that's off topic. However, threaded calls on the *same SmbFile
instance are NOT thread safe*. This is exactly the same as the regular
java.io.File class. For example, you would not want to have multiple
threads call exists() on the *same* SmbFile or java.io.File instance. You
can call exists() or whatever other method on *different* SmbFile instances
interleaved with as many threads as you can throw at it. Look at some
of the example programs that use threads. The most intense is probably
T2Crawler. This will crawl over an entire network using many threads. If
you want many users to access the same resource/file/directory create
a new SmbFile instance for each access. As described below this has
little overhead if the SmbTransport/SmbSession/SmbTree has already been
established. I suspect you already conform to this because it would be
necessary anyway to ensure the appropriate credentials are used.

Mike

> >When an SmbFile as provoked to retrieve information about it's peer
> >(the real file on a server somewhere) it asks the socket layer for an
> >appropriate SmbTransport. If one has already been extablished it uses
> >that. Then it will ask that SmbTransport for an SmbSession matching the
> >provided user credentials. If a matching SmbSession for that SmbTransport
> >has already been established it will use it. An analygous check is used
> >for an SmbTree (share) on that SmbSession. So this forms a tree of cached
> >SmbTransports (based on host address and port), SmbSessions (based on
> >username, password, and domain), and SmbTrees (based on share name).
> >
> >With repect to your issue, when user credentials do NOT match an
> >established SmbSession, a new SmbSession is created by sending the
> >encrypted users credentials to the server hosting the file or directory of
> >interest. The file server will then contact the domain controller on your
> >behalf validating the users credentials. If successfull the SmbSession is
> >created. If not successfull, the SmbSession is failed to be established
> >and the error is traped, converted to an SmbAuthException and thrown.
> >
> >So let me just make up a scenario here. Let say you have some servlets
> >and each provides access to a resource on the same smb server. Different
> >users will "login" providing different authentication credentials. For
> >the first user a new SmbTransport followed by and SMbSession and SmbTree
> >to the resorce will be create. THe second user however will only
> >need to extablish a new SmbSession and SmbTree. So the SmbTransport
> >will be shared. If we extend this idea, if with each call the same
> >user credentials are sublitted the *same SmbSession* will be used to
> >service the call. This is actually about as efficient as it get's I
> >think. However, it would not be very polite to keep these SmbTrees,
> >SmbSessions, and SmbTransports established forever. For this reason they
> >are dropped after short period of time. The jcifs.smb.client.soTimeout
> >property might be of particular interest to you. It controls when the
> >SmbTransport to a server is dropped along with any SmbSessions and
> >SmbTrees. The default is 15 seconds. You might increase this value.
> >
> >Now after having said all that there may be an issue. I beleieve servlet
> >engines use separate ClassLoaders to load the environment for each
> >individual servlet instance. This will effectively cause an entirely
> >new jCIFS client instance to be created and may turn out to be horribly
> >slow, not to mention breaking all of the caching described above. It's
> >effectively the same as running an entirely new VM for each connection and
> >is a terrible waste. If you can figure out how to share a ClassLoader
> >between all of your servlet instances for creating SmbFiles this would
> >probably turn out to be far more efficient.

-- 
May The Source be with you.