It would use more memory and since there is already 2x IoProcessors for cpu cores there would be no speedup. In fact it would lead to more memory fragmentation/cache misses and require one thread for every session.
Basically, it would be a bad idea. On Oct 7, 2015 3:36 PM, "Марат Гайнуллин" <[email protected]> wrote: > Dear sirs! > It is completely clear for me, that decoding of a buffer must be linear > and tcp messages fragments must be decoded in a serial manner. My question > is about different thing. Why not to decode SEPARATE sessions' data streams > in parallel? > 7 окт. 2015 г. 10:18 PM пользователь "Jon V." <[email protected]> > написал: > > > 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" <[email protected]> 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 ! > > > > > > > > >
