On 2/2/12 3:53 PM, Antonio Rodriges wrote:
Suppose session is the reference to the same session throughout
1) when a message is not yet transferred since last session.write
call, if a thread calls session.write does the message goes to queue
and no part of it is transferred until the previous message is done?
Depends. If you have added an unordered ExecutorFilter into your chain, then
it can happens. The default behavior is that once each session is attached
to one single IoProcessor, it will be fully enqueued before another write
for this very session can be enqueued.
So, when an unordered ExecutorFilter is in action, it can reassign a
session to a different IoProcessor?
No, but you have no guarantee whatsoever that a message X will be sent
*before* another message Y, even if you called the session.write(X)
*before* session.write(Y).
My previous response was not accurate.
The way it works internally is simple :
- when a new session is created, it's associated with an IoProcessor
(round robin is used)
- every time a message is received, it will be processed by the selector
associated with an IoProcessor, so it can't be processed by another.
- then the message is propagated to the Handler through the filters chain
- during this propagation, one single thread is used
- unless you have an executor in the chain, and then, the message is
processed by another thread, which has a reference to the Session, so to
the original IoProcessor.
The direct consequence is that message will always be processed by the
original IoProcessor that the session was attached to when it was
created, and this will never change.
However, as I said, there is one outgoing message queue, and the message
will be pull out of this queue one by one, in the order they have been
pushed into, and sent to the remote peer. No other message for this
session will be sent until the current message is completely sent. If
you have an executor, the only thing that is not guaranteed is the order
of the messages _before_ they are injected into the queue.
It's easy to think about a use case where 2 messages are written into
the chain in a specific order (X at t0 then Y at t1) but sent in the
reverse order (Y at t2 then X at t3) : if you have an executor in your
chain, and if X takes a lot of time to be encoded, then Y may be encoded
faster and then sent before X.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
