Re: ProtocolCodecFilter threading model

2015-10-07 Thread Jon V.
Yeah like if you have a blocking database lookup then you would use the executor filter to allow a bunch of blocking operations to occur without blocking the entire IoProcessor. The executor filter is not really supposed to make things faster. On Oct 7, 2015 3:50 PM, "Марат Гайнуллин" wrote: > Hi

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Emmanuel Lécharny
Le 07/10/15 22:34, Марат Гайнуллин a écrit : > Hi Emmanuel! > > According to last Jon message, there are already cores*2 IoProcessors > involved in network processing. It changes everything. It seems, that > executor filter is useless at all if a server doesn't perform any > waiting/sleeping,

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Марат Гайнуллин
Hi Emmanuel! According to last Jon message, there are already cores*2 IoProcessors involved in network processing. It changes everything. It seems, that executor filter is useless at all if a server doesn't perform any waiting/sleeping, etc in its further logic (handler for example). It seem

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Emmanuel Lécharny
Le 07/10/15 21:40, Jon V. a écrit : > 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. Beside that, it would be impossible to kn

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Марат Гайнуллин
Hi, Jon! Thak you for information about IoProcessors. If there are already cores*2 IoProcessors, than things change much. It seems, that executor filter is useless at all if a server doesn't perform any waiting/sleeping, etc. It seems, that executor filter helps, when there are waiting/sleeping

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Jon V.
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, "Марат Гайнуллин" wrote

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Марат Гайнуллин
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." н

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Jon V.
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-

Re: ProtocolCodecFilter threading model

2015-10-07 Thread Emmanuel Lécharny
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

ProtocolCodecFilter threading model

2015-10-07 Thread Марат Гайнуллин
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? If several threa