[zeromq-dev] XPUB/XSUB missed messages

Kenneth Adam Miller kennethadammiller at gmail.com
Fri Jan 2 21:06:25 CET 2015


I added pub-sub tracing, and I can see that when they miss messages,
nothing is sent at all on the network. Is it possible that it could take a
little bit of time for a subscription to make it to the XPUB/XSUB, and that
the messages are beating it there?

On Fri, Jan 2, 2015 at 2:05 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150102/b1a8b7ab/attachment.htm>


More information about the zeromq-dev mailing list