In my experience, ZMQ_PAIR sockets exhibit some problems that I previously documented here: https://github.com/zeromq/libzmq/issues/2759, specifically around disconnecting and reconnecting.
In particular, see this reply from Simon: https://github.com/zeromq/libzmq/issues/2759#issuecomment-389057453 > I now think that this might be problematic because disconnect works > asynchronously, and a new connect would be allowed only after the disconnect > completed. You could add a socket monitor to wait for the > ZMQ_EVENT_DISCONNECTED event to synchronize this. This gibes with Luca’s explanation. (The bit about using socket monitor is of course not going to help in this case, since you’re trying to troubleshoot the socket monitor itself ;-) On top of that, I’ve had conversations with the original implementor of socket monitoring, who has said that socket monitoring was intended to be used for logging/troubleshooting, not for state/control flow. This makes sense when you understand that monitor events are themselves asynchronous with respect to the underlying socket operations — for instance see the caveats in the doc: > ZMQ_EVENT_CONNECTED > > The socket has successfully connected to a remote peer. The event value is > the file descriptor (FD) of the underlying network socket. Warning: there is > no guarantee that the FD is still valid by the time your code receives this > event. > I don’t know what you’re trying to accomplish with socket monitor, but it may not be the best choice. > On Dec 12, 2018, at 8:50 AM, Luca Boccassi <[email protected]> wrote: > > On Tue, 2018-12-11 at 22:07 +0000, [email protected] > <mailto:[email protected]> wrote: >> Hi, >> >> I'm experimenting with zmq_socket_monitor(). I have a XSUB socket >> that I'm monitoring. The monitoring works fine. I'm just trying to >> understand how I can enable/disable monitoring back-and-forth by >> calling zmq_socket_monitor(). >> >> I tried to enable/disable/re-enable monitoring by invoking >> zmq_socket_monitor() as shown below I get the error "Address already >> in use" on the 3rd invocation. >> >> 1) zmq_socket_monitor(my_xsub_sock, "inproc://starship-enterprise", >> ZMQ_EVENT_ALL); >> 2) zmq_socket_monitor(my_xsub_sock, NULL, 0); >> 3) zmq_socket_monitor(my_xsub_sock, "inproc://starship-enterprise", >> ZMQ_EVENT_ALL); <- ERROR >> >> I followed the source code for zmq_socket_monitor() to a method >> called zmq::socket_base_t::monitor(). That function eventually calls >> zmq_bind() where I believe the error occurs. >> >> 1) The first time zmq_socket_monitor() is called a ZMQ_PAIR socket is >> created (_monitor_socket) and bound to address "inproc://starship- >> enterprise". Note that this socket is created with ZMQ_LINGER=0. >> >> 2) The second time zmq_socket_monitor() is invoked to disable >> monitoring _monitor_socket is closed and because ZMQ_LINGER=0 it >> should go out of existence right away. Right? >> >> 3) The third time zmq_socket_monitor() is called I get "Address >> already in use" as if the old socket is still there. How can that be? >> >> Regards, >> Martin > > Without looking with gdb, my best guess is a race: the close is > asynchronous and non-blocking, so the third call might try to re-use > the same endpoint that is still technically in use. > IIRC inproc sockets events are processed from the "connecting" socket's > thread, so try to run something (ie: zmq_getsockopt zmq_events) on the > connecting inproc before the third call and see if that helps. > > -- > Kind regards, > Luca Boccassi_______________________________________________ > zeromq-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
