Emmanuel Lecharny wrote:
Thanks for the detailed explanation, Emmanuel. I actually understood most
of this pretty well already, though, as I've been digging through the code
quite extensively to try to understand what was going on.
Hmmm... Sounds like we may have a new committer sooner or later ;)
lol
Perhaps. Gotta be careful digging through code or you catch the
"committer" disease. :-) Well, I'm starting with bug reportings and
such right now; we'll see where that leads down the road.
But that does not happen. Instead, the write operation gets performed in
the IoProcessor thread.
That's not what happen. In fact, of course, the IoProcessor *is*
processing the write, _but_ the thread selected by the Executor will
do all the processing before (including the encoding), and then
enqueue the result for the IoProcessor to deal with it later.
Hmmm .... OK. I guess that's what I've been seeing happen then. I
guess the reason it didn't look like anything was happening in my
executor thread was because I was testing with the TextLineCodecFactory,
and so didn't have any debugging output going on in the encoding step.
I'll have to think about this all a bit then and try to figure out
whether it's worthwhile for me to have a writer thread pool. My server
has both a text and a binary protocol, and the binary one does do some
work to encode output messages, so it might still be worthwhile.
But according to DefaultIoFilterChain.HeadFilter, it looks like the *head*
of the filter chain, not the tail, is what's writing the output out to the
socket:
Yes, it sounds strange, but it makes sense (somehow). The requests are
injected into the Head, processed down the chain up to the Tail, and
back. Again, that does not sounds a very good idea to me, as it's
confusing. With two chains, that would be easier to understand. But in
any case, this is plain normal.
Ah, I get it. Incoming requests traverse the chain from head to tail,
and outgoing responses traverse from tail to head. Wish I knew that the
other night before I did my code diving! :-)
Makes some sense now that I know what's going on. I guess, yes,
conceptually it would be an improvement to have 2 chains. Only issue I
could see would be if this somehow hurt performance. One of the things
I like about MINA is its speed.
Did I succeeded in bringing a faint light on the obscure side of MINA ?
Yes, definitely. And thanks much for taking the time to read my
long-winded email, and write a helpful response, by the way.
By the way, I think I neglected to say so earlier, but just wanted to
make sure to say: thanks much to you and the rest of the dev team for
all the hard work you've put in on building MINA. It's a great framework!
DR
