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 !
