[zeromq-dev] Weird zmq_receive behavior on blocking

Sean McKay sean at on-track-solutions.com
Tue Jun 9 03:26:07 CEST 2009


Hi,

 

I'm not sure if this is a bug or not - if it isn't, I would appreciate
someone explaining this behavior to me as I have spent over 3 hours on
tracking down a bug with messages not being sent.

 

Consider I have three applications (or threads) in C#.  

.         The first one has a local queue/exchange pair of Receiver/Sender

.         The second one has two global exchanges (one to application one,
and one to application three) and a queue called One:Two:Sender,
Three:Two:Sender, and Two:Receiver

.         The third application has a local queue/exchange pair of
Three:Receiver / Three:Sender

 

The Sender/Three:Sender are bound to Two:Receiver, and One:Two:Sender is
bound to Receiver, and Three:Two:Sender is bound to Three:Receiver.

 

 

In essence, a round trip message may look like:

 

 

ONE                                      TWO
THREE

Request Do X ------=>  Forward Do X--------=> Do X

Process Result <=------- Forward Result <=--- Send Result of X

 

The problem I was finding was that I could send my command successfully to
application THREE, but when I tried sending the result to TWO the message
disappeared without any error.  I tried all sort of variations  of things to
fix this [many of which were silly to be honest], I discovered that toggling
off the block parameter for the zmq_receive caused my results to be
forwarded on in the manner I expected.  And while I am glad to have my
simple round trip working properly, the drawback of no longer blocking is
that my receive loops suck up CPU time.

 

So, is this working as designed?  If so, are there any best practices for
how to maintain responsiveness on listening without impacting the CPU?

 

I was able to reproduce this issue with 0.6 and later with 0.6.1.

 

Thanks,

 

Sean

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090608/de00ac36/attachment.htm>


More information about the zeromq-dev mailing list