Blocking zmq_proxy_steerable with PUSH backend and SUB frontend

[rikvdh]

Today I found out that zmq_proxy_steerable blocks after TERMINATE command via the control socket and when no-one is listening to the push socket. When then an incoming connection reads from the PUSH socket, the proxy is stopped.

I understand that the PUSH blocks when no listeners are there, but expected behavior is that the proxy stops when TERMINATE is sent.

    zmq::context_t context(1);
    std::string bind, con;

    zmq::socket_t frontend(context, ZMQ_SUB);
    frontend.connect("tcp://127.0.0.1:2345");
    frontend.setsockopt(ZMQ_SUBSCRIBE, NULL, 0);

    zmq::socket_t backend(context, ZMQ_PUSH);
    backend.bind("tcp://127.0.0.1:1234");

    zmq::socket_t control(context, ZMQ_SUB);
    control.connect("tcp://127.0.0.1:12345");
    control.setsockopt(ZMQ_SUBSCRIBE, NULL, 0);

    // Start the proxy
    zmq_proxy_steerable(frontend, backend, NULL, control);

[hintjens]

Yes, the proxy should stop. Do you want to look at the code and propose a
fix?

On Fri, Apr 24, 2015 at 1:23 PM, Rik van der Heijden <
notifications@github.com> wrote:

Today I found out that zmq_proxy_steerable blocks after TERMINATE command
via the control socket and when no-one is listening to the push socket.
When then an incoming connection reads from the PUSH socket, the proxy is
stopped.

I understand that the PUSH blocks when no listeners are there, but
expected behavior is that the proxy stops when TERMINATE is sent.

zmq::context_t context(1);
std::string bind, con;

zmq::socket_t frontend(context, ZMQ_SUB);
frontend.connect("tcp://127.0.0.1:2345");
frontend.setsockopt(ZMQ_SUBSCRIBE, NULL, 0);

zmq::socket_t backend(context, ZMQ_PUSH);
backend.bind("tcp://127.0.0.1:1234");

zmq::socket_t control(context, ZMQ_SUB);
control.connect("tcp://127.0.0.1:12345");
control.setsockopt(ZMQ_SUBSCRIBE, NULL, 0);

// Start the proxy
zmq_proxy_steerable(frontend, backend, NULL, control);

—
Reply to this email directly or view it on GitHub
#1382.

[rikvdh]

@hintjens I'm already on it. But I'm wondering, what is the best way to fix it.

I've already created a test which reproduces the problem. I found out that is blocks in the send-routine of the forward function in src/proxy.cpp:85. This was expected because the PUSH socket blocks here when the message is not delivered. But in the parent zmq::proxy, a message arrived for the control socket. But this is never reached.

Making the send non-blocking when a control-socket is attached can drop messages which conflicts with the spec.

Another option is to spawn the control handling in a different thread and stop the send (if busy) somehow.

A third option would be to pass along control messages within socket via a new zmq_setsockopt and react to the TERMINATE message.

A last resort would be fixing the documentation, and let the application make sure that the socket is pulled before terminating.

[rikvdh]

@hintjens Can you please respond, I can't proceed with fixing this issue without input from your side.

[hintjens]

Sorry, I missed your comment. The correct solution is IMO to only receive from the frontend when the back​end is able to receive messages (poll out is true). This will take a little work on the code.

[rikvdh]

@hintjens Shall I backport this or do you?

[hintjens]

I've backported to 4-1. It doesn't patch cleanly to 4-x, so if you want to
make that pull request to the zeromq4-x repo, I'll merge it, thanks.

On Fri, May 1, 2015 at 11:22 AM, Rik van der Heijden <
notifications@github.com> wrote:

@hintjens https://github.com/hintjens Shall I backport this or do you?

—
Reply to this email directly or view it on GitHub
#1382 (comment).

[hintjens]

There's some stuff missing in Makefile.am, I'm pushing a pull request for
that.

On Fri, May 1, 2015 at 11:27 AM, Pieter Hintjens ph@imatix.com wrote:

I've backported to 4-1. It doesn't patch cleanly to 4-x, so if you want to
make that pull request to the zeromq4-x repo, I'll merge it, thanks.

On Fri, May 1, 2015 at 11:22 AM, Rik van der Heijden <
notifications@github.com> wrote:

@hintjens https://github.com/hintjens Shall I backport this or do you?

—
Reply to this email directly or view it on GitHub
#1382 (comment).

[rikvdh]

This one is fixed, it can be closed. :)