mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: MINA 3.0 Acceptor/Processor
Date Sat, 02 Jun 2012 14:38:00 GMT
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 ?

View raw message