[zeromq-dev] XPUB/XSUB missed messages

[Kenneth Adam Miller]

Fixed it-rather than connect and immediately send, I just kept the
publisher and reused it.

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

> 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/97f8f1e8/attachment.htm>