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 < kennethadammil...@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 < > kennethadammil...@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... >> > >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
