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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
