Salut,
that one we haven't discussed, but I do think we need to take it into
account. The question is should we allow the user to decide between
NIO.1 or NIO.2, or based on the JDK version, fallback to NIO.1 if NIO.2
isn't supported? Or do we want a TCPNIO2TransportHandler (and
TCPNIO1)...ouf :-)
For those of you that haven't add a chance to look at nio.2, a simple
example is the following (which is quite close to Alexey's proposal):
> // create the listener
> final AsynchronousServerSocketChannel listener =
> AsynchronousServerSocketChannel.open().bind(new InetSocketAddress(port));
>
> // accept connections
> listener.accept(null, new CompletionHandler<AsynchronousSocketChannel,Void>() {
> public void completed(IoFuture<AsynchronousSocketChannel,Void> result) {
> AsynchronousSocketChannel channel;
> try {
> channel = result.getNow();
>
> // handle the new connection
> protocolChain.execute(....);
>
> } catch (IOException x) {
> System.err.println(x);
> System.exit(-1);
> }
> }
> });
With NIO.2, our ProtocolChain/Filter API will works almost as it is.
Probably the ReadFilter will have to be re-worked, and things like
SelectionKey removed. The CompletionHandler API allow us to pass an
attachment (grrr another evil things...but that's another blog I
reserver to myself :-)) so if we decide to use attachment (issue 3),
then I guess we can easily port it to NIO.2 (rrr :-)).
My proposal is to design Grizzly 2.0 that NIO.1 or NIO.2 are handled
almost the same. But I don't like closed framework (something I'm so/so
with MINA) where you can access the object under the hood. Hence I would
still like to reach SelectionKey or CompletionHandler from Grizzly.
A+
-- Jeanfrancois