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.
On Sat, Jan 9, 2010 at 11:07 PM, Emmanuel Lecharny <[email protected]> wrote: > hakan eryargi a écrit : >> >> hi, >> >> how can i guarantee messages are processed in arrival order and >> sequantially (one is processed after previous is completed) for >> NioSocketAcceptor ? >> > > This is guaranteed, as soon as you don't inject an ExecutorFilter in your > chain (see [1] for more info about this point). The way incoming messages > are processed by MINA is pretty simple : each opened socket is associated > with a selector, itself associated with a IoProcessor. IoProcessor uses a > single thread to process this message, but to insure some scalability, we > spawn more than one IoProcessor, and we also use a queue (the backlog) for > messages waiting to be processed when the thread is busy. So the order will > always be respected, as the next message can only be processed when the > current message has been completely processed. > > The biggest issue with this approach is that each message is considered > having the very same priority, and a message neeeding a long processing will > block all the other messages. More important, you will block messages from > other sessions too. That's painful, and this is one of the reason the > ExecutorFilter has been added. >> >> i guess, as tcp guarantees packet order, for each IoSession message >> order is guaranteed. but if messages are passed to IoHandler in a >> multi-threaded manner there could be cases process order is different >> from arrival order. >> > > [1] This is where the ExecutorFilter comes into the picture : it creates a > way to process more than one message at the time (or kind of...). The > drawback is that you may have more than one message of a specific session > being processed in parallel. This can be avoided by teling the > ExecutorFilter to use a OrderedThreadPoolExecutor. > > Hope it helps. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > >
