cool. my server is using blocking io at the moment, with two threads (read/write) for each connection. once a message is read, it's processed in reading thread, with no explicit queing and hence message order in session is preserved but message order among sessions are subject to race condition.
seems as with an ExecutorFilter with an OrderedThreadPoolExecutor or without an ExecutorFilter i will get the very same behaviour. that's easy porting :) On Sun, Jan 10, 2010 at 12:12 AM, Emmanuel Lécharny <[email protected]> wrote: > 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 > > >
