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 ?
Thanks,
Rajiv
-----Original Message-----
From: Emmanuel Lécharny [mailto:[email protected]]
Sent: Monday, July 09, 2012 2:08 PM
To: [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.
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.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
