[zeromq-dev] Weird zmq_receive behavior on blocking

Sean McKay sean at on-track-solutions.com
Thu Jun 18 16:38:20 CEST 2009

This version only has the C# code so as to fit under the ML constraints...

-----Original Message-----
From: Sean McKay [mailto:sean at on-track-solutions.com] 
Sent: Tuesday, June 16, 2009 3:37 PM
To: 'Martin Sustrik'
Cc: 'zeromq-dev at mail.imatix.com'
Subject: RE: [zeromq-dev] Weird zmq_receive behavior on blocking

Hi Martin,

I apologize for the long delay.  I am behind on a number of tasks, and just
got a chance to make a "small" subset of the code that reproduces the bug.
I regret I don't have the time to make it even shorter. 

There is a slight difference between the possible bug I originally reported
and what this application shows -- it doesn't reveal itself until the last
step in the round trip.  So it will go from Request to Manager to Worker to
Manager and stop there for some reason.  The original issue I reported
stopped between the Worker sending to the Manager.

To turn on the bug (the non-blocking _working_ version is currently used)
_zmqServer.Receive(out inMessage, out type, false);


_zmqServer.Receive(out inMessage, out type, true);



-----Original Message-----
From: Martin Sustrik [mailto:sustrik at fastmq.com]
Sent: Tuesday, June 09, 2009 2:08 AM
To: Sean McKay
Cc: zeromq-dev at mail.imatix.com
Subject: Re: [zeromq-dev] Weird zmq_receive behavior on blocking

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: QueueBug.7z
Type: application/octet-stream
Size: 5237 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090618/fa36b9a0/attachment.obj>

More information about the zeromq-dev mailing list