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
