Le Wed, 10 Feb 2010 13:28:11 -0800, "Alan D. Cabrera" <l...@toolazydogs.com> a écrit :
> > On Feb 4, 2010, at 4:53 AM, Emmanuel Lecharny wrote: > > > 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... > > I tried to follow the code for IoProcessor and my brain hurts. :) > Did I read correctly that the sessions are partitioned between N > IoProcessors? If so, seems kinda odd and I agree, what you propose > seems more straightforward. > > > Regards, > Alan > > Now you understand the pain of maintaining this spaghetti. Last bug proved it well. I think Emm still feel the pain. It's behaving equals or better, I agree the code will be a lot simpler and put NIO crap in a corner. -- Julien Vermillard Archean Technologies http://www.archean.fr
signature.asc
Description: PGP signature
