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. 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 ? > 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
