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

Axel R. axelriet at gmail.com
Thu Nov 2 18:05:14 CET 2023


@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?

@Lei: it is documented that message “frames” is a contraption related to building messages in memory, not to how they are sent over the wire. The “more” flag apparently just waits for more content before sending anything and all the “frames” are sent as one message when you are done adding. Also I’m not sure why empty “frames” would be needed at all, unless they are placeholders for bits added or removed by hops along the way. 

—Axel

Sent from my iPhone

> On Nov 2, 2023, at 06:45, Brett Viren via zeromq-dev <zeromq-dev at lists.zeromq.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20231102/26d904a3/attachment.htm>


More information about the zeromq-dev mailing list