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. > > 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? > and is released to pool only after session is closed. And at this point it is > available to process other request from clients. Was my understanding > incorrect. When an event is processed, a thread is used, and wil be released only wthen the execution has been completed for this event, thus the thread will be avaiblable for another session. Understood this point. -- Regards, Cordialement, Emmanuel Lécharny <http://www.iktek.com> www.iktek.com
