Just thought it would be good if we can consider JCA stuff here. I believe there was a discussion long ago, of using MINA under that spec. Not a master on JCA, but if we can consider this aspect as well, would be great.
On Thu, Feb 4, 2010 at 6:23 PM, Emmanuel Lecharny <[email protected]> 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... > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
