I have got more clarity on the issue I raised here. Since I am using executor, mina picks a thread on a random basis from the thread pool and uses it to perform the asynchronous tasks. So there is no guarantee of the same thread id being used for message handling and session closing. I have enhanced my logging to get complete information of session handling.
Thanks and Regards, Rajiv -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Monday, July 09, 2012 4:36 PM To: [email protected] Subject: Re: sessionClosed called twice Le 7/9/12 12:45 PM, Rajiv Kasera a écrit : > Thanks for further clarification. Below are my answers/queries in red. > > > > Regards, > Rajiv > > -----Original Message----- > From: Emmanuel Lécharny [mailto:[email protected]] > Sent: Monday, July 09, 2012 4:04 PM > To: [email protected] > Subject: Re: sessionClosed called twice > > > > > > comments inlined... > > > > Le 7/9/12 12:20 PM, Rajiv Kasera a écrit : > >> This is how I am handling the threads using the executorfilter. >> acceptor.getFilterChain().addLast( "logging", >> new LoggingFilter() ); >> acceptor.getFilterChain().addLast( "codec", new >> ProtocolCodecFilter( new CentralCodecFactory(false))); >> >> acceptor.getFilterChain().addLast("threadPool", new >> ExecutorFilter(Executors.newCachedThreadPool())); > > > Why are you using an executor ? Is there any good reason for doing so ? > > I am working with a legacy code and I am assuming that this was added to > support multi-threading and achieve scalability. I would appreciate if there > is a better alternative available to this approach. Simply get rid of the executor, unless you have an absolute need for one (see below). You may have very long processing in the handler, and in this case, using an executor may allow other sessions to be processed, but this has some side effects that are difficult to manage (like having a lot of threads being used, killing the advantage offered by NIO...) > >> Thanks, >> Rajiv >> -----Original Message----- >> From: Emmanuel Lécharny <mailto:[mailto:[email protected]]> >> [mailto:[email protected]] >> Sent: Monday, July 09, 2012 2:08 PM >> To: <mailto:[email protected]> [email protected] >> Subject: Fwd: RE: sessionClosed called twice CC'd the mailing list... >> So does it mean that there is no tight coupling between the thread and the >> session. > There is no coupling between a thread and a session. The session stores the > current state, and the execution is done by a thread which is selected when a > new event is processed by the selector. > > Understood this point. > >> I was under impression that a thread will be tied to a session >> till it is not closed > That's not the case. However, what happens is that we select a thread in the > pool and we try to always use this thread, to limit the contention (piking a > thread from a pool is not a free operation). This implies that a session will > always be executed by the same thread. > > If the same thread is chosen for finally closing the session, it means that > the selector will be blocked till the time the thread is available in the > pool. Especially for a scenario mentioned above where same thread is attached > with 6 sessions, if any thread took around 40-50sec (which is possible in our > application) the sessions won’t close till that time. Does that also mean > that the socket also remain open for that duration? > The problem here is that it takes 50 seconds to close the session, which is insanely long. However, as you have an executor, you should be able to process this close event without blocking the thread that was used when you decided to close the session. An executor can be used to process any kind of events, ncluding the sessionClosed event. In this case, when the executor receives the sessionClosed event, it will select a new thread in the executor pool, and will free the initial thread. Isn't it what you have implemented in your code ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
