hakan eryargi a écrit :
thanks, that's quite descriptive :)
speaking of blocking, how is IoSession.write(message) is handled ? all
sessions share same thread pool ? is there a chance writing messages
is blocked because one end point is not reading ? as possibly you
know, that can be the case if a single or limited number of threads
are used to write to blocking socket streams: if one end point is not
reading and socket's buffer is full, thread will be blocked till some
space is available in buffer.
To be clear : if you don't have an executor Filter, then it will use the
thread, so until the message is queued to be written in the socket,
nothing else can happen on this session.
If you have an ExecutorFilter, it's a bit more complicated, as you may
or may not use the executor to process the write. It's possible to tell
the filter which kind of event has to pick a new thread from the pool.
So it's up to you, but in many case, I'm not sure it's useful to let the
filter pick a dedicated thread to handle the write, unless you have a
slow encoder (but even then, as you can only have one single exector
filter in the chain, that may be a problem, as this executor can't be
put before and after the codec).
Regarding the sessions, yes, they all share the same pool.
Your last point, known as the 'slow client problem', is not an issue at
least from the thread POV. Once the message reach the end of the chain,
it is pushed into a queue wiating for the socket to be ready for write.
Now, that leads to something different to deal with : potential OOM
errors. You have to handle the idle event, and kill the long lasting
message by closing the malevolent sessions.
Life stinks ;)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
