[zeromq-dev] how to reliably wait for SUBscribers to connect before sending messages

KIU Shueng Chuan nixchuan at gmail.com
Fri Jan 5 12:52:03 CET 2018


Message: 1
Date: Fri, 5 Jan 2018 10:03:17 +0100
From: Francesco <francesco.montorsi at gmail.com>
To: zeromq-dev <zeromq-dev at lists.zeromq.org>
Subject: [zeromq-dev] how to reliably wait for SUBscribers to connect
        before sending messages
Message-ID:
        <CAKW0qij8-yJBiyGqBaEeQpNOtAhz2hAFwx1wEQsFdmd4RsH9Hg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,
I have some unit tests around the ZMQ wrappers I wrote for PUB/SUB sockets
(these wrappers integrate functionalities specific to my use case).

In these unit tests I spawn a thread that creates a PUB socket and another
one creating a SUB socket. In the PUB thread I do zmq_bind(), then sleep
for a SETTLE_TIME and then I start sending messages with zmq_msg_send().
In the SUB I just do zmq_connect() and then immediately zmq_msg_recv().

The problem is when I run such unit tests under valgrind. In that case I
noticed that randomly my settle time of 1sec is not enough: the unit tests
fail because the SUB receives 0 messages instead of N>0.
A simple fix would be to increase the settle time. However since I repeat
that kind of tests hundreds of times, that means increasing testing time a
lot.

I think my problem is that I need to wait after the zmq_bind() and before
zmq_msg_send() some time to allow ZMQ background threads to actually
connect the PUB and SUB sockets together.
Is there a better way to test if there are pending connections in ZMQ
background threads rather than waiting a (random) amount of time?

------------------------------


If you could change to use XPUB socket, after binding you could wait for
the subscription message to know that the subscriber had connected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180105/bfbe659f/attachment.htm>


More information about the zeromq-dev mailing list