In all cases, push/pull communications are complete (all 10 000 messages received) and pub/sub communications lose some messages (it is not a constant number).
lost message - #3501 value is 3721 (220 dropped messages)
lost message - #8721 value is 8758 (37 dropped messages)
NB: this is NOT a late joiner problem because dropped messages are in the middle of the sequence, not in the beginning. We ensured this by running the receiver before the sender and waiting 2 seconds before sending messages.
NB: of course the problem appears only when sent messages are more than 1000, which is the default HWM value...
What's the expected result?
When using _zsock_setsndhwm and _zsock_setrcvhwm on all socket to set HWM to zero, one would expect all the messages to be delivered in PUB/SUB communications, just like it is done in PUSH/PULL.
Issue description
When setting HWM to 0 in PUB/SUB communications, limits seem to still apply and cause messages to be dropped.
Environment
Minimal test code / Steps to reproduce the issue
A sender and a receiver using both pub/sub and push/pull as a comparison.
Sender:
Receiver:
Used on tcp and ipc transports this way (tested on same and two computers for TCP):
What's the actual result?
In all cases, push/pull communications are complete (all 10 000 messages received) and pub/sub communications lose some messages (it is not a constant number).
NB: this is NOT a late joiner problem because dropped messages are in the middle of the sequence, not in the beginning. We ensured this by running the receiver before the sender and waiting 2 seconds before sending messages.
NB: of course the problem appears only when sent messages are more than 1000, which is the default HWM value...
What's the expected result?
When using _zsock_setsndhwm and _zsock_setrcvhwm on all socket to set HWM to zero, one would expect all the messages to be delivered in PUB/SUB communications, just like it is done in PUSH/PULL.