[zeromq-dev] Majordomo worker API destroy worker socket

Pieter Hintjens ph at imatix.com
Mon Feb 18 11:39:33 CET 2013


Good point. The DEALER socket will reconnect, yes. In the text of the
Guide, where we discuss mdwrkapi, it says:

"You might wonder why the worker API is manually closing its socket
and opening a new one, when 0MQ will automatically reconnect a socket
if the peer disappears and comes back. Look back at the Simple Pirate
and Paranoid Pirate workers to understand. Although 0MQ will
automatically reconnect workers if the broker dies and comes back up,
this isn't sufficient to re-register the workers with the broker. I
know of at least two solutions. The simplest, which we use here, is
for the worker to monitor the connection using heartbeats, and if it
decides the broker is dead, to close its socket and start afresh with
a new socket. The alternative is for the broker to challenge unknown
workers when it gets a heartbeat from the worker and ask them to
re-register. That would require protocol support."

Hope that helps.


On Mon, Feb 18, 2013 at 8:36 AM, Martijn Rijkeboer <zeromq at bunix.org> wrote:
>>> In the s_mdwrk_connect_to_broker function of the Majordomo worker API
>>> the worker socket is destroyed and recreated. What is the reason for this
>>> since, according to the zguide, ZeroMQ reconnects automatically?
>> This is how to reset after a lost reply message when using a REQ
>> socket. You can't send another message on the same socket since REQ is
>> blocked waiting for the reply.
> This would be the case if it were a REQ socket, but in this case it is a
> DEALER socket and there is a timeout used on the poller so that shouldn't be
> an issue.
> Kind regards,
> Martijn Rijkeboer
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list