You also cannot process a linear buffer simultaneously. TCP is linear and reading the messages must be linear. After you have a list of messages then you may execute them in parallel but the line decoding of the buffer must be single threaded. The decoder operates on an inbound buffer and multi-threading this process will cause the buffers to complete out of order. There is also no guarantee that the inbound buffer contains a complete message. In this scenario the tail end of a message could be processed before the previous part which makes the whole thing totally broken without locks and locks would just eat more cpu with zero gain. On Oct 7, 2015 2:53 PM, "Emmanuel Lécharny" <elecha...@gmail.com> wrote:
> Le 07/10/15 20:44, Марат Гайнуллин a écrit : > > Dear sirs! > > I am happy to know, that DIRMINA-1013 has been fixed. > > I have a question. I think, that while decoding TCP messages in separate > > sessions, server SHOULD do it in parallel. Why your last comment on > > DIRMINA-934 was about not to put executor filter before decoder in TCP? > Because doing so will put your server atrisk. Note that you already have > more than one thread processing incoming messages (IoProcessors) and TCP > does not guarantee you that a message will be delivered in one piece. > Now, let's assume you have an exectir *before* the decoder : then for > one specific session, more than one thread might be used to decode a > message, which means that potentially, for fragmented messages, more > than one thread will be in charge of decoding fration of a message. this > simply does not fly... > > For separate sessions, there is absolutely no problem, because each > session might be handled by a different IoProcessor. > > Performance wise, you might object that while a message is being > decoded, then another session could be blocked because the thread is > busy decoding (as the two sessions are handled by the same IoProcessor > thread). that would be true, except that when an IoProcessor thread is > busy decoding, it uses 100% of the CPU of the core it run on, so there > is no 'room' for some other exacution. So having an executor before the > decoder is simply useless, unless you haven't declared as many > IoProcessors as you have core on your server. > > The only case where it's annoying is when your decoder is accessing > external resources and has to wait for them : unlikely... > Hope it helps ! > >
