[zeromq-dev] A bit too reliable ;)

[sven.koebnick at t-online.de]

Hey, I had a comparable idea for shutting down. 

BUT: a shutdown
command in a system that stops and respawns during normal runtime is
never ever something that can be treated as a typical
bcast/fire-and-forget and so should never be able to reach some worker
that is not meant to get it. 

Such a thing always is rcpt specific, so
just handle it like that, and you are fine. 

In my system, I used the
socket-IDs for subscribing a "subject". That way, it is possible to
reach each single service. 

The bad thing is, that subjects are for
sub-sockets and you wont get an answer for this shutdown request. 

To
avoid this, you could stick to req/rep and implement your own filter to
just ignore requests, that are marked as instance specific with a
special instance ID. Just answer "not for me" and the sockets keep in
sync. 

^5 

sven 

Am 2015-01-10 20:42, schrieb Daniel Krikun: 

>
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 [1]




Links:
------
[1] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150112/be154a55/attachment.htm>