[jcifs] 2 important things about jcifs-0.6b!

Michael B.Allen mballen at erols.com
Sun Nov 18 04:56:19 EST 2001


I forgot to mention that the attributes of SmbFile are cached
for a breif period of time. You can set this time using the
jcifs.smb.client.attrExpirationPeriod property. The default is
100ms. There are a bunch of methods that use this information. For
example, if you make a call to say isHidden() and then immedeately call
canRead() (sort of a wierd thing to do but ...) there will only be one
network message sent to the server. This has the potential to create some
problems however. If you reference the same file using two different
SmbFile objects, changing one will not be reflected in the other for a
tenth of a second. Doesn't seem like a big deal but it could be if by
some strange occurance you do something like:

SmbFile aFile =    new SmbFile( "smb://foo/bar/baz.iso" );
SmbFile sameFile = new SmbFile( "smb://foo/bar/baz.iso" );

try {
	if( aFile.exists() ) {
		sameFile.delete();
	} if( aFile.exists() ) {
		System.err.println( "The file still exists!?!?" );
	}
} catch( SmbException se ) {
	System.err.println( se.getMessage() );
}

The above would likely do the unexpected and print 'The file still
exists!?!?'. This is because the file was deleted using the sameFile
instance. If it had been deleted using the aFile instance it *would*
do the expected because calling delete resets the variable keeping track
of the attribute expiration.

Also, I fogot to mention another new property. The jcifs.smb.maxBuffers
property controls the maximum number of buffers to create in the buffer
pool for doing network io and transactions. The default is 16 but unless
your doing crawling this should not be reached. I think 2 bufferes are
needed per host (one for encoding outgoing messages and one for decoding
incoming messages). Then another 2 buffers are needed for outstanding
transactions. So the client will likely use at a minimum about 4 buffers.

However, the crawler example, needs quite a few of these buffers. With
only 16 you'll see them quickly become exhausted after connecting to only
5 or 6 hosts (10 to 12 buffers leaves 4-6 for pending transactions). The
client will stall. As sockets timeout and buffers are freed you'll see
little bursts of activity. If you are crawling you need to set maxBuffers
to more like 200 and use fewer threads. I have found that 3-4 threads
gives better performace and if you can think of a way to tie 1 or at
most 2 threads per host you'd also be better off. Of course you'd have
to play with the parameters a bit to find what's optimal.

Mike




More information about the jcifs mailing list