Le Thu, 04 Feb 2010 13:53:50 +0100, Emmanuel Lecharny <elecha...@gmail.com> a écrit :
> I have reviewed the way we use the Selector in MINA 2.0. Here are > some of the thoughts I have about teh way we use them for Sockets : > > We currently have a system built on top of three elements : > - IoAcceptor on the server side > - IoConnector on the client side > - IoProcessor which are processing the messages received or sent > > IoAcceptor and IoConnector are just two sides of the same coin : a > IoService. The only difference is that the Connector initiates the > communication. > > Nio Sockets > ---------------- > In order to deal with incoming connections, the IoAcceptor uses a > Selector on which are registered the ServerSocketChannel for the > OP_ACCEPT event. On the client side, we have the same Selector but > the ServerSocket is registered for the OP_CONNECT event. > > In both case, once the session is connected/accepted, the associated > Channel is attached to another Selector, itself associated with an > IoProcessor. > > Here, I'm questioning the fact that we use more than one Selector to > handle connect/accept and read/write operations. The select() > operation is not specially costly, even if it does a lot of things : > - deregister the canceled channels > - each channel which has had some operation since the last select is > put to a set of selected keys > - deregister the canceled channels again (for channel which has been > canceled while the step 2 was processed) > - return the number of keys found ready in step 2 > > but all in all, this is a fast operation, as it just reads some bit > fields to determinate if something has changed since the last select. > Even if we have one million registered keys in the selector, first > the number of active channel will be low, and second the processing > time for this step is very minimal compared to the application > processing time. > > Now, wouldn't it be better to have only one selector, and then > dispatch the tasks to some processor? > > On the server side, we have to deal with : > - newly added sessions > - recently closed sessions > - incoming data > - outgoing data > > On the client side, we have to deal with : > - newly connected sessions > - recently closed sessions > - incoming data > - outgoing data > > each of those tasks can be processed by a separate thread selected in > a thread pool. IMO, it may be better than the current architecture > where we have a pool of IoProcessor, each one of them having its own > Selector, and no thread to process the events. For instance, if we > have 3 IoProcessor (the default value for a dual core processor), > then we can only process 3 events in parallel. Pretty inefficient... > If we can use only 1 selector, I would be pretty happy because it'll simplify a lot of code. But I won't accept those concepts without a bench :) What would be the most efficient ? A thread polling and feeding a pool of threads in charge of doing the costy operations (read/write/accept). Or a pool of threads selecting and doing the costy operations ? On paper and without seeing the NIO/concurrency oddities I think I can't answer this question. -- Julien Vermillard Archean Technologies http://www.archean.fr
signature.asc
Description: PGP signature
