I'm using an inproc xpub/xsub setup to manage graceful shutdown of a
multi-threaded system. Here's a diagram:
T1 T2 .....
/ | \ / | \
s1 s2 s3 - > s1 s2 s3 - >
^ / ^ /
\ ----------<- \ ----------<-
The blue is a loopback reactive Loopback, which has callbacks.
The first two sockets in each thread, s1, and s2, say, are sub sockets
connected to an XPUB/XSUB configuration just as shown here:
https://github.com/imatix/zguide/raw/master/images/fig13.png
Basically, when any thread decides to do a kill, it can knock out either an
entire loopback, and just that loopback, or the whole system, and it all
goes down gracefully. When a specific loopback is killed, it is sent with
the unique subscription string local<ID> where ID is a atomically
incremented number returned in the loopback code. The way this works is
simple-it creates a new socket, connects it to the xpub/xsub configuration,
and sends a kill string prefixed with local<ID>. Upon receipt, the callback
defined for s1/s2 for the thread sets a boolean and the loopback terminates.
My problem is that most of the time, the loopbacks seem to be getting
message-I know for certain that if they get the message, they will
terminate. After debugging, there is one central theme-the subscribers
sometimes not getting the messages.
In the kill code, the connection is made, the kill immediately sent and the
socket subsequently closed and eliminated. I've accounted for all sockets,
and they get closed and handled. So, I've kind of ruled out the possibility
of subscribers subscriptions not making it to publishers when publishers
connect late with a test of my own.
Basically, I'm not looking to push this xpub xsub connection to tcp out
over the wire-what kind of design solution could I pursue that would allow
me to make certain that the subscribers - agnostic of however many are
connected to the xpub/xsub - receive the kill messages, whether it be to a
specific loopback or to them all? What could be causing XPUB/XSUB to drop
them? I read over chapter 5, and none of them seem to really make fit my
architecture...
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
