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 Sat, 02 Jun 2012 15:13:20 GMT
Le 6/2/12 4:38 PM, Julien Vermillard a écrit :
> On Fri, Jun 1, 2012 at 2:28 PM, Emmanuel Lécharny<elecharny@gmail.com>  wrote:
>> 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 !
> spinning selector bug is fixed in JDK6 no ?
Not to my knowledge...

Emmanuel Lécharny

View raw message