[zeromq-dev] A bit too reliable ;)

[Justin Karneges]

One thing you could do is have commands associated with a particular
child process lifetime. So when a child starts up, it sends a message to
the master process with a unique id representing itself as a running
instances, and then when a master sends a shutdown message it would
include this id. Child processes simply ignore messages from the master
if the id doesn't match the child's run id.

On Sat, Jan 10, 2015, at 11:42 AM, Daniel Krikun wrote:
> Hello,


> I have a problem which seems to arise from zeromq reliability
> behaviors.
>
There is a master that spawns few processes which perform some tasks on
its behalf; eventually the master sends a message over PUSH socket (one
for each process) to shutdown itself. After some time the master can
respawn the processes and so on.
>
The problem emerges when one of the child processes crashes prematurely:
the master still sends the shutdown message, the child process receives
it and shuts down mistakenly.
>
While I can think of at least 2 solutions: timestamping (to detect an
obsolete message), or heartbeat (to avoid sending shutdown message to a
dead process), I thought, there must be a way for master to "reset" a
connection *before* spawning the child process in order to purge
outgoing messages.
>
I tried to close() a socket but that didn't help.

> I'm using libzmq-2.2.0, TCP transport on a single Windows 7 x64
> machine.


> Thanks!


> _________________________________________________
> zeromq-dev mailing list zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150110/4453c93d/attachment.htm>