mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: MINA 3.0 Acceptor/Processor
Date Fri, 01 Jun 2012 12:28:09 GMT
Le 5/31/12 8:55 PM, Julien Vermillard a écrit :
> Hi,
> In mina 2 the event loops are composed of Acceptor/Connector (for
> accepting/connecting TCP sessions) and IoProcessor for handling
> session read and write events. For each service you need at least one
> Acceptor/connector and one IoProcessor, so at least two threads. For a
> simple TCP base asynchronous proxy it sould be doable with one thread.
Yep. Same for UDP.
> The IoProcessor for TCP and for UDP are totally differents, the TCP
> one select TCP client sockets the UDP one handle read write event
> passed by the Acceptor because you have only one socket in a UDP
> server.
> Ayway this logic make the code uber complicated, what I propose :
> Two technical event loop construction :
> A SelectorProcessor, his work is to select SelectableChannel for IO
> event (read, write, accept) and push events to listeners (e.g.
> TcpServer for accept events, UdpServer for read events on new
> sessions)
> A EventProcessor, his work is to process read/write events coming from
> SelectorProcessor using session chains with one thread event.

I like the idea to have an EventProcessor instead of the IoProcessors. 
The semantic is way better.
> So we can wired SelectorProcessor and EventProcessor like we want,
> from just one SelectorProcessor for a one thread logic for quick
> server, to multiple SelectorProcessor pushing event to multiple
> EventProcessors.
> I think it'll make the code really simpler, testable with mock and
> more modulable.
Yes, absolutely.

Now, there is still one tricky thing we have to deal with : at some 
point, we may want to separate the SelectorProcessor to process some 
specific OP events, instead of having one single SelectorProcessor to 
manage all the events. In MINA 2, we had one thread dealing with 
OP_ACCEPT only, and N IoProcessors dealing with the other OP events. We 
would like to be able to keep this logic, but in a simpler way : at some 
point, it doesn't matter how many SelectorProcessors we will use, but 
one of them will handle the OP_ACCEPT events, and may spread the 
SelectableChannels on the other SelectorProcessors.

We may need to conduct some performance tests here, to know how costly 
it is to process hundred of thousands of SelectableChannel on one single 
selector vs spreading those SelectableChannel across many selectors.

One of the reasons it might be necessary to have more than one selector 
on TCP is the JDK select spinning bug : in some cases, the select() 
method just become crazy, eating 100% CPU, and the only way to get out 
is to delete the selector, create a new one, and register all the 
SelectableChannel on the newly created selector... An expensive operation !

Emmanuel Lécharny

View raw message