ZMQ_DEALER seems to be dropping messages even though HWM should be cause blocking
Description
Environment
Linux, Mac OS X
Attachments
2
Activity
Show:
Martin Sustrik October 28, 2011 at 9:50 AM
It's expected behaviour. The problem can be alleviated by limiting the TCP buffers (ZMQ_SNDBUF, ZMQ_RCVBUF).
Martin Sustrik October 11, 2011 at 10:10 AM
Yes. The pushback applies only after the TCP buffers (and HWMs) are full.
Mikko Koppanen October 11, 2011 at 9:56 AM
From your comment I understand that this is expected behaviour?
Martin Sustrik October 11, 2011 at 9:30 AM
I've tried commenting the sleep(1) out. The sender blocks after sending 26295 messages, when both tcp tx and tcp rx buffers are full.
PieterP October 5, 2011 at 2:31 PM
If you reverse the bind/connect order, presumably it works? Looks like a bug caused by there being no active connections at all.
The documentation states:
"When a ZMQ_DEALER socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any zmq_send(3) operations on the socket shall block until the exceptional state ends or at least one peer becomes available for sending; messages are not discarded."
However when I run the attached scripts locally the DEALER socket seems to be discarding messages as the memory usage of the programs is not going up. It starts accepting messages as soon as the remote peer connects.