[zeromq-dev] Weird zmq_receive behavior on blocking

Martin Sustrik sustrik at fastmq.com
Tue Jun 9 09:08:19 CEST 2009


Hi Sean,

> 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.

Is this happening immediately on the startup of the components? Try 
starting the components, waiting a while a then sending the request. 
Doest it work that way?

If so, check whether your exchanges are declared with load-balancing 
style - that should prevent dropping messages while the components are 
not yet physically connected.

If not so, it's probably a bug and a test program to reproduce the 
behaviour would help us to fix it.

Martin



More information about the zeromq-dev mailing list