[zeromq-dev] Improper use of PAIR sockets?

Bob Clarke optionguy71 at gmail.com
Sat Aug 8 20:38:52 CEST 2015

I am developing a Windows application in C++ using 0MQ 4.1.2. The app will
listen for machine status updates from up to eight data centers in the US
and Europe. The server(s) are working fine, but it's inside the GUI client
that a problem occurs.

The GUI client contains one Listener object per data center, and each
Listener stores some information obtained from its server. Some Listeners
never get created because the user may not care about that data center
(different use cases).

The Listeners connect to a SUB socket and a REQ socket for acting on server
messages, bind to an inproc PAIR socket for acting on UI requests, then sit
in a polling loop, watching for messages. Each Listener uses Windows
messages to communicate with the UI, and when the UI needs something from a
Listener, it communicates via a local variable inproc PAIR socket: create
and connect with the PAIR socket, ask the Listener for something, get the
reply, set Linger to 0, close and delete (via destructor) the PAIR socket.
The user is often just watching the app, but they may click on something
for more information, which is why the UI then talks to a Listener, instead
of the app creating PAIR sockets and leaving them open.

The problem is that, eventually, the UI hangs and I have been able to
consistently trace it back to a Listener's PAIR socket receiving a request,
but then not returning. The number of Listeners does not seem to matter; I
have disabled all but one and the problem still occurs. The hang may occur
soon after the app starts and the user starts clicking around, or it may
take hundreds of UI requests to a Listener for the hang to occur.

I have not taken the time to distill this down to a small program yet. But,
is this an improper use of the PAIR sockets?


Bob Clarke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150808/dcff826f/attachment.htm>

More information about the zeromq-dev mailing list