[zeromq-dev] Proxy with inproc frontend

Goswin von Brederlow goswin-v-b at web.de
Mon Feb 3 17:01:10 CET 2014

On Mon, Feb 03, 2014 at 06:57:11AM -0800, Cosmo Harrigan wrote:
> Hi,
> I have a scenario where I want multiple simultaneous event handlers to
> publish ZMQ messages on one PUB socket. To do so, I used the following
> design:
> Create two sockets, call them sockA (XSUB) and sockB (XPUB)
> Bind sockA to the inproc endpoint
> Bind sockB to the tcp endpoint
> Start a proxy forwarder device with sockA as the frontend, and sockB as the
> backend
> Whenever an event occurs, an event handler thread is created, in which a
> socket is created; call it sockWn
> Connect sockWn to the inproc endpoint
> (***)
> Send one message on sockWn
> Close sockWn
> The problem is, the proxy device loses almost all of the messages, unless I
> insert a sleep statement where I marked (***).
> Reviewing the guide and past forum posts, I think this is due to the slow
> joiner syndrome, where the XSUB sockA doesn't know about the new PUB sockWn
> until after it has already sent its message. (Excerpt included below)
> However, in this design, where creating a new event handler is an extremely
> frequent occurrence, and the code inside each event handler is very
> lightweight and will only send one message, I am wondering what would be
> the recommended solution?

Don't create threads like that. Create a thread pool of handlers that
keep their sockets connected and dispatch events to them. That solves
your problem and also cuts down on the (rather long) time to start a
thread per event.

> Is there any way for sockWn to verify that sockA is connected to it? Unlike
> many cases where a publisher should not know who is connected to it, in
> this particular use case over inproc (not tcp), the PUB sockWn explicitly
> expects to have XSUB sockA listening to it. That's why XSUB sockA did bind,
> and PUB sockWn did connect.

Why use PUB/SUB then? Why not PUSH/PULL or something else?
> I appreciate any suggestions.
> Thanks,
> Cosmo


More information about the zeromq-dev mailing list