[jcifs] SmbTransport thread accumulation issues

[Sebastian Sickelmann]

Am 18.10.2011 20:59, schrieb Michael B Allen:
> BTW: I tried NIO once. Once. It is a crumby implementation of
> select(2) from UNIX (which was always considered by many to be a
> rather crude design in itself). NIO should be called "NoIO". I had
> trouble just getting it to work reliably. And note that NIO would not
> really help that much. It would only help in this particular case
> where you want to communicate with 100 servers in parallel. Otherwise,
> JCIFS is actually extremely efficient. The CIFS protocol allows for
> multiplexing requests. Meaning you can send request A and B and get
> the response for B before A. And JCIFS fully utilizes this. JCIFS can
> touch every file on a workstation in under 10 seconds if the server
> cache is hot. If the non-blocking implementation in Java were better I
> might consider using it. But it's not.
>
> Mike
>
Hi Mike,

you are right if you say that selector implementation (introduced
in java 1.4) isn't the easiest part to implement against. And
can lead very quick to the meaning that the socket-part of the
NIO in Java 1.4 should be nearly named "NoIO". But i have done
this part of porting on jcifs (in my private local git-branch) and
even if i am not finished with it, it actually works quite good.
And yes i hate that selector implementation too.

Java 7 introduces new classes for Asynchronous Network IO
(AsynchronousSocketChannel) with CompletionHandling. This
really makes the task easier to use asyn-network-io. But i think
jcifs is implemented against the java5 feature-set. Am i right
with the latter?

-- Sebastian