[zeromq-dev] content based routing for a thread pool

Brett Viren bv at bnl.gov
Thu Nov 2 18:19:35 CET 2023

"Axel R." <axelriet at gmail.com> writes:

> @Brett: You wrote:
>     Not reliability per se but messages will not be recv()'ed in the order
>     that they were send()'ed when zeromq is configured with more "I/O"
>     threads than the default.
> This is a little concerning: how increasing the number of threads results in out-of-order delivery, unless
> the default is 1? What are the circumstance where messages should be expected to arrive out-of-order?

I think there is no need to worry.  The default is that messages are

Normally, applications should/would not even know there is a "knob" to
add more I/O threads.  Only if one is trying to push beyond 20-25 Gbps
through a single TCP transport is this even worth considering.  IMO,
if this high level of performance is truly required one is doing
something sophisticated enough to either deal with out-of-order or to
find another way to get multiple TCP transport streams while keeping
order (eg, multiple processes).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20231102/46c70834/attachment.sig>

More information about the zeromq-dev mailing list