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]> 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 , 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：-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]>
> 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]
> 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
