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

[Brian Granger]

Hi,

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
session:

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://127.0.0.1:5555')                s.bind('tcp://127.0.0.1:5555')
s.setsockopt(zmq.SUBSCRIBE,'')
# Wait for a while to allow connection...
                                                              s.send('foo')
s.recv(zmq.NOBLOCK) # Nothing!
                                                              s.send('bar')
s.recv(zmq.NOBLOCK) # 'bar'
                                                              s.send('bam')
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?

Cheers,

Brian

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