<div style="word-wrap:break-word">Arun;<div><br></div><div>I agree with the method used in the gist linked in your email: </div><div><br></div><div>First check amqp_frames_enqueued(). If this returns true, there are decoded frames ready, amqp_simple_wait_frame() will not block.</div>
<div><br></div><div>Second check amqp_data_in_buffer(). If this returns true, there is data that has already been received (with recv()) but not decoded. It is likely if you call amqp_simple_wait_frame() it will not block. However if the data in the buffer doesn't complete a frame, recv() will be called and may block.</div>
<div><br></div><div>Third, call select() or poll() on the socket associated with the connection (you can use amqp_get_sockfd() to get the socket descriptor). If this system call shows that the socket can be read from amqp_simple_wait_frame() will call recv() and likely won't block - assuming a full frame is received.</div>
<div><br></div><div>As you may notice the last two steps don't give you a "correct all the time" answer to whether amqp_simple_wait_frame() will block or not. In practice I've found the majority of the time the above works well enough for RPC-style AMQP messaging for the following two reasons:</div>
<div>1. When the broker sends data - typically it sends it as an entire frame, if your select() call returns that there is data in the buffer likely you already have, or soon will have an entire frame ready to be read by recv()</div>
<div>2. AMQP is intended to be run on a low-latency, high-bandwidth LAN, so if you do get a partial frame when recv is called, within a short time period you will receive the rest of the frame, otherwise it is likely something serious has happened and that will cause the whole connection to die at some point in the near future (possibly time out - which I grant you can possibly block for a lengthy amount of time).</div>
<div><br></div><div>There is definitely room for improvement in the rabbitmq-c library handles non-blocking behavior.</div><div><br></div><div>HTH</div><div>-Alan</div><div><br></div><div><div><div>On Feb 15, 2012, at 2:28 PM, Brett Cameron wrote:</div>
<br><blockquote type="cite">Arun,<div><br></div><div>I'd look at implementing something along the lines of what Alex describes in the link using select() or poll(). Have cc'd Alan for his consideration as to how this might best be done. The approach outlined by Alex in the link is okay, but you could still potentially find yourself hanging on a blocked read if something bad happened between the initial check for data available and a read operation. An alternative might be to add a timeout parameter to the wait_frame call or create a variant of this function that includes a timeout...</div>
<div><br></div><div>Regards,</div><div>Brett</div><br><div class="gmail_quote">On Thu, Feb 16, 2012 at 7:58 AM, Arun Chandrasekaran <span dir="ltr"><<a href="mailto:visionofarun@gmail.com" target="_blank">visionofarun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br><br>How do we make a non blocking recv from librabbitmq? amqp_simple_wait_frame blocks if the queue doesn't contain any message.<br>
<br>Should we call amqp_data_in_buffer() and based on the result call amqp_simple_wait_frame or implement a solution like this?<br><br><a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-September/014868.html" target="_blank">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-September/014868.html</a><br>
<br>Thanks in advance.<span><font color="#888888"><br><br>- Arun</font></span><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div>