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." <sybersn...@gmail.com>
написал:
> 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 !
> >
> >
>
