On Mon, Jan 28, 2013 at 12:13 AM, Emmanuel Lécharny <[email protected]>wrote:
> Le 1/27/13 10:21 PM, Jeff MAURY a écrit : > > Hello, > > > > I started to review the Mina3 code and I have a couple of points I want > to > > share with you: > > > > 1) It is possible to close all existing connections established by a > > client, the method is called disconnect (BTW a log message is issued but > > with an address which is the last one connected so it may be confusing), > > but there is no corresponding method for the server: the unbind method > > simply stop listening for new connections but existing ones are kept > alive. > > I think we should align for the server but we should rename it like > release > > or shutdown but we need to think about the lifecycle of those service > > objects: once this method has been called, can the user call again > connect ? > This is absolutely right : we need to add a method that shutdown the > server as we have one for the client. > > However, those methods are semantically different : > - a client can close a connection at will > - a server must be cautious when shuting down as some client can still > expect some messages. > I think we should have the same requirements for client and server: when you stop them, you may want them so send the queued messages or not. > > In MINA 2, we had a dispose() method which can be immediate or differed > (ie, the server will not accept any new request, but will cleanly wait > for all the current resquests to be proceeded before closing the > connections.) > > We should implement the same kind of behavior in a MINA 3 server. > > 2) I noticed that some threads are created through the SelectorPool > > implementations, and those threads are lost forever when the client or > > server is gargage collected. Is there any reasons why the implementations > > are not related to the Java Executor framework. We should think of a > > release mechanism when the SelectorPool has been allocated by the > IOService. > Can you be a bit more explicit ? Where are thos threads created ? > When you create a NioTcpClient (see line 70), 1) you create a NioSelectorLoop --> 1 thread created 2) you create a FixedSelectorLoopPool (with 2 as second argument) --> creates 2 NioSelectorLoop -> creates 2 threads > > 3) In order to get even better performances, I spoke with Emmanuel about > > the NIO2 asynchronous operations. Since then, I looked at the Windows and > > Linux/MacOS implementations and it seems thy do more or less what Mina > did > > before: a thread is issuing epollctl instead of select and there is > > registration/unregistration mechanism against this thread. I don't think > we > > might get much improvement but I have started a little POC just to know. > Okie, great. The question is more about the lists of activated > SelectionKeys are managed in NIO2, because this is probably the > operation that costs the most in the select() method (there are a lot of > synchronized sectons in this part of the operation). We need to > investigate this part so having a POC is a good thing. > > Thanks for the heads up ! > > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
