[zeromq-dev] New bug in pub/sub since multipart

Brian Granger ellisonbg at gmail.com
Fri May 14 21:05:10 CEST 2010


I am in the process of making sure the Python zeromq test suite passes
with the new multipart message stuff.  We have a simple pub/sub tests
that is failing, that used to pass.  Here is an outline of the

Process #1                                              Process #2

import zmq                                              import zmq
c = zmq.Context()                                    c = zmq.Context()
s = c.socket(zmq.SUB)                            s = c.socket(zmq.PUB)
s.connect('tcp://')                s.bind('tcp://')
# Wait for a while to allow connection...
s.recv(zmq.NOBLOCK) # Nothing!
s.recv(zmq.NOBLOCK) # 'bar'
s.recv(zmq.NOBLOCK) # 'bam'

Each process was typed interactively, so the time scales between
everything are long (seconds) - plenty enough time for zeromq to
connect, send/recv.

I am wondering if the underlying problem is the following.
Previously, the topic and message was sent in a single send
("topicmessage").  Now the idea is that you can send the topic and
message are parts:

s.send_multipart(['topic','message'])  # the python version.

But, what happens with pub/sub sockets now if the message only has 1
part (like my example).  In other words, the topic and message are
sent as 1 part?  What is the desired behavior?  Should this still
work?  Do we always require a min of 2 parts for a pub/sub socket?



Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the zeromq-dev mailing list