[jcifs] jTDS + jCIFS works!

Eric Glass eric.glass at gmail.com
Thu Jul 22 17:46:40 GMT 2004

> Let's assume (for the sake of argument and because I'm not familiar with
> the protocol) that TDS requires the client to be responsible for
> handling timeouts.  This is what the current jTDS TCP/IP implementation
> does.  When it receives an InterruptedIOException after setting the
> socket timeout, it immediately creates a "cancel" packet and sends it to
> the server.
> Would it be less kludgy (dare I say "cleaner"?) to implement a timeout
> mechanism in jTDS to do the query timeout?  I don't relish the thought
> of reviewing code to make sure that killing a thread in the middle of
> execution won't leave any objects in a bad state.
> Are there other, better ways of doing this?

For a TCP transport, this is probably an acceptable approach; the
problem with using a similar approach for named pipes is that there
are potentially lots of things happening over the connection (possibly
including other user's sessions).  Even if you prevented multiplexing
and tweaked jCIFS to allow a per-transport timeout as mentioned above,
there's a good possibility you'd still encounter issues; when the
timeout occurs, the TCP connection underlying the transport will be
closed immediately.  To send the cancel packet mentioned above, you
would have to reconnect and establish a new SMB session to the server.
 I'm not sure how SQL Server would treat that (as the request is
coming from a separate "conversation").

Your best bet would probably be experimenting with the SMB transaction
timeouts.  I'm not terribly familiar with that area, unfortunately;
Mike might be able to provide more details.  I *think* you'd be
looking at the "timeout" field of some of the SmbComTransaction
subclasses (TransCallNamedPipe maybe?).  I don't really know how that
would work, but you might try setting it to a few values and see what
happens.  Ideally, what would happen is you'd get an SmbException when
the transaction times out, and then handle that the same way you're
handling it for TCP (sending the cancel message).  If you could get it
working using hardcoded values etc., Mike might be amenable to
tweaking the jCIFS classes to support the functionality in a
"standard" fashion (i.e. TransactNamedPipeOutputStream.setTimeout() or


More information about the jcifs mailing list