Hi Chris: > The difference seems to be that if the PUB socket sends a message prior to > any SUB sockets connecting, then later subscriptions are subject to the slow > joiner problem.
If I understand you correctly, you’re saying that the SUB doesn’t receive the first message — but that’s to be expected, since it was sent before the sub connected. I believe the SUB socket should receive the second message, however. Is that what you’re seeing? Bill > On May 10, 2019, at 5:11 PM, Chris Billington <[email protected]> > wrote: > > Hi BIll, > > Thanks for the response. > > Connect may be synchronous, but after more experimentation, it looks like the > processing of subscriptions is not, or at least not in some circumstances. > The following blocks on recv(): > > import zmq > > ctx = zmq.Context() > pub = ctx.socket(zmq.PUB) > sub = ctx.socket(zmq.SUB) > > pub.bind('inproc://test') > pub.send(b'hello') > sub.connect('inproc://test') > sub.subscribe(b'') > pub.send(b'hello') > print(sub.recv()) > > The difference seems to be that if the PUB socket sends a message prior to > any SUB sockets connecting, then later subscriptions are subject to the slow > joiner problem. For me since the two sockets are initially in the same > thread, I can get around this by using an XPUB instead and calling recv() on > it after the subscription was sent. This seems to ensure that the > subscription has been processed. But if I have misunderstood anything, please > let me know :) > > -Chris > > On Fri, May 10, 2019 at 2:05 PM Bill Torpey <[email protected] > <mailto:[email protected]>> wrote: > Hi Chris: > > With inproc transports the connect call is synchronous, as opposed to with > other protocols (like TCP) where the connect is asynchronous. This was part > of a discussion with Simon at > https://github.com/zeromq/libzmq/issues/2759#issuecomment-389185969 > <https://github.com/zeromq/libzmq/issues/2759#issuecomment-389185969> , but I > have still not found this described elsewhere in the “official” docs. (There > is another reference here: > https://grokbase.com/t/zeromq/zeromq-dev/1343mv38cr/inproc%EF%BC%9A-message-dropped-after-zmq-dealer-connected > > <https://grokbase.com/t/zeromq/zeromq-dev/1343mv38cr/inproc%EF%BC%9A-message-dropped-after-zmq-dealer-connected> > ) > > Note also that the disconnect is NOT synchronous, which can lead to problems > if you disconnect and then immediately try to connect again — if the socket > has not finished disconnecting, the second connect will fail. > > Regards, > > Bill > >> On May 10, 2019, at 1:46 PM, Chris Billington <[email protected] >> <mailto:[email protected]>> wrote: >> >> The below pyzmq code sends a message on a PUB socket to a SUB socket via >> inproc, without doing any kind of welcome messages or anything to get around >> the slow joiner problem, and does not appear to drop messages. However if I >> change the endpoint to a TCP one, then it is subject to the slow joiner >> problem and the subscriber doesn't receive the initial message, as expected. >> >> import zmq >> >> ctx = zmq.Context() >> pub = ctx.socket(zmq.PUB) >> sub = ctx.socket(zmq.SUB) >> >> pub.bind('inproc://test <>') >> sub.subscribe(b'') >> sub.connect('inproc://test <>') >> pub.send(b'hello') >> print(sub.recv()) >> >> >> Is inproc guaranteed to not be subject to the slow joiner problem? Or am I >> just getting lucky with not seeing messages dropped in my test? Since inproc >> does not use separate IO threads, it stands to reason that slow joining >> might not be an issue. If so, this would be great as it would allow me to >> use simpler code for inproc PUB SUB. >> >> Regards, >> >> Chris >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> > > _______________________________________________ > zeromq-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
