[jcifs] question on fixes in 1.1.6

[Michael B Allen]

Actually from looking at these a little closer I think these might be
related to some kind of network failure. Specifically if there is a socket
error and the transport thread tries to close stuff while operations are
in progress I think these sorts of errors can result.

roy-jcifs at xemaps.com said:
> jcifs.smb.SmbException: The handle is invalid.
> 	at jcifs.smb.SmbTransport.send(SmbTransport.java:704)
> 	at jcifs.smb.SmbSession.send(SmbSession.java:234)
> 	at jcifs.smb.SmbTree.send(SmbTree.java:103)
> 	at jcifs.smb.SmbFile.send(SmbFile.java:724)
> 	at jcifs.smb.SmbFile.copyTo0(SmbFile.java:1935)
> 	at jcifs.smb.SmbFile.copyTo(SmbFile.java:2034)

This one is coming from the server. If an error occurs, things are closed,
and the timing is such, this is the sort of error that would pop up.

> java.lang.NullPointerException
>         at jcifs.smb.SmbTransport.tryClose(SmbTransport.java:283)
>         at jcifs.smb.SmbTransport.start(SmbTransport.java:316)
>         at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:888)
>         at jcifs.smb.SmbTransport.hasCapability(SmbTransport.java:266)
>         at jcifs.smb.SmbFile$WriterThread.<init>(SmbFile.java:1809)
>         at jcifs.smb.SmbFile.copyTo(SmbFile.java:2014)

This one is claiming the sessions member is null which I don't see is
possible since it's created in the SmbTransport constructor. I suppose
something in listIterator() is null perhaps because the sessions are
actively being closed (e.g. due to socket failure).

> java.lang.NullPointerException
>         at
> jcifs.smb.AndXServerMessageBlock.readWireFormat(AndXServerMessageBloc
> k.java:99)
>         at jcifs.smb.SmbTransport.run(SmbTransport.java:483)
>         at java.lang.Thread.run(Thread.java:534)

In this case the 'in' socket is null which is passed to the readXxx
methods by the transport. Again if a socket error occurs while operations
are in-flight this is the sort of thing that could happen.

I'm not certain I should try to hunt down and kill these. The transport
layer is a little fragile and I don't want to futz with it just to
gracefully deal with socket failure.

Incidentally it so happens that at this very moment I'm working on a new
Transport abstract base class for 2.0 that synchronizes everything with a
single lock. Currently jCIFS uses a couple of locks which is just asking
for big trouble.

You would be surprised how difficult it is to write serious network
software in Java. Simple one caller / one thread / one socket stuff is
trivial but when you're multiplexing I/O like we are the Java thread model
and network facilities are pretty bad.

Mike

Mike