Huge refactoring for NIO transports in trunk

[Trustin Lee <tr...@gmail.com>]

Hi,

Today, I checked in a load of code that removed a lot of duplicate
code.  Let me list the changes I've made:

* Added IoProcessor interface

This is a very thin reactor layer that provides abstract view over
various selector-style I/O processors.

* AbstractIoFilterChain becomes DefaultIoFilterChain

By removing duplicate doClose and doWrite implementations and using
IoProcessor interface, I was able to make AbstractIoFilterChain
non-abstract.  All existing filter chain implementations have been
replaced with DefaultIoFilterChain.

* Added AbstractIoProcessor class

This implements IoProcessor.  Most part of the code has been extracted
from SocketIoProcessor, but should work fine with any selector-style
I/O processors.  I wish Julien could experiment with this class to
implement APR transport.

* Added NIOSession (extends AbstractIoSession) class

DatagramSessionImpl and SocketSessionImpl extends it now to provide
common properties to NIOProcessor.

* Replaced SocketIoProcessor with NIOProcessor

NIOProcessor extends AbstractIoProcessor and implements all required
abstract methods.  NIOProcessor can work with SocketChannels and
connected DatagramChannels.

* DatagramConnector uses NIOProcessor

Because NIOProcessor supports any kind of selectable ByteChannel,
connected datagram channels can be handled with NIOProcessore, too.
This also means DatagramConnector can be multi-threaded.   Although I
didn't do that yet, it should be a piece of cake.

On the other hand, an acceptor-side datagram channel has very
different communication style.  I have no idea on how to reduce code
duplication in this case.  Please let me know if you have any good
idea.

I hope you like these changes, and I believe this refactoring will
help people other transports more easily.  Any feed back is welcome!

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Huge refactoring for NIO transports in trunk

[Julien Vermillard <jv...@archean.fr>]

On Sun, 16 Sep 2007 23:29:03 +0900
"Trustin Lee" <tr...@gmail.com> wrote:

> Hi,
> 
> Today, I checked in a load of code that removed a lot of duplicate
> code.  Let me list the changes I've made:
> 
> * Added IoProcessor interface
> 
> This is a very thin reactor layer that provides abstract view over
> various selector-style I/O processors.
Very nice, actually for the APRConnector, I copy/pasted/cleaned
SocketIOProcessor

> 
> * AbstractIoFilterChain becomes DefaultIoFilterChain
> 
> By removing duplicate doClose and doWrite implementations and using
> IoProcessor interface, I was able to make AbstractIoFilterChain
> non-abstract.  All existing filter chain implementations have been
> replaced with DefaultIoFilterChain.

Nice, to see you changed it quickly :)

> 
> * Added AbstractIoProcessor class
> 
> This implements IoProcessor.  Most part of the code has been extracted
> from SocketIoProcessor, but should work fine with any selector-style
> I/O processors.  I wish Julien could experiment with this class to
> implement APR transport.

Anyway due to last trunk commit my APRIOProcessor is borked, so I'll
need to digg into IoProcessor anyway.

> 
> * Added NIOSession (extends AbstractIoSession) class
> 
> DatagramSessionImpl and SocketSessionImpl extends it now to provide
> common properties to NIOProcessor.
> 
> * Replaced SocketIoProcessor with NIOProcessor
> 
> NIOProcessor extends AbstractIoProcessor and implements all required
> abstract methods.  NIOProcessor can work with SocketChannels and
> connected DatagramChannels.
> 
> * DatagramConnector uses NIOProcessor
> 
> Because NIOProcessor supports any kind of selectable ByteChannel,
> connected datagram channels can be handled with NIOProcessore, too.
> This also means DatagramConnector can be multi-threaded.   Although I
> didn't do that yet, it should be a piece of cake.
> 
> On the other hand, an acceptor-side datagram channel has very
> different communication style.  I have no idea on how to reduce code
> duplication in this case.  Please let me know if you have any good
> idea.
> 
> I hope you like these changes, and I believe this refactoring will
> help people other transports more easily.  Any feed back is welcome!
> 
> Trustin

Well actually it broken my code, but I think it's for the good of
MINA ;) Most of transport will probably share the IOProcessor model of
the current NIO transport implementations.

Perhaps I should push APRConnector out of my sandbox as soon as I
resolved some issues.

Julien