<div class="gmail_extra">Monish;</div><div class="gmail_extra"><br></div><div class="gmail_extra">As a short answer: there the rabbitmq-c does not provide an easy-to-use interface to deal with basic.return messages from the broker.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The long answer: it is possible, with a bit of work:</div><div class="gmail_extra"><br></div><div class="gmail_extra">The easy part: reading a basic.return message from the broker, its almost the same as a basic.deliver of a message:</div>
<div class="gmail_extra">- Read the method (1 frame), only instead of a basic.deliver, you get a basic.return method</div><div class="gmail_extra">- Read the message header (1 frame)</div><div class="gmail_extra">- Read message body (1+ frames)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Example code:�<a href="https://github.com/alanxz/rabbitmq-c/blob/master/examples/amqp_consumer.c#L75">https://github.com/alanxz/rabbitmq-c/blob/master/examples/amqp_consumer.c#L75</a>� Note that line 83 will need to compare against AMQP_BASIC_RETURN_METHOD instead of AMQP_BASIC_DELIVER_METHOD</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">That's the easy part, the hard part requires a bit more�explanation:</div><div class="gmail_extra"><br></div><div class="gmail_extra">As you can already tell the rabbitmq-c client works a bit differently from the Java and C# clients in that it doesn't have its own internal event loop that deals the the�asynchronous�bits of AMQP, so using the library forces you to think about how you're going to handle these�asynchronous�messages from the broker.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The first thing to note is that basic.publish method is an asynchronous[1] AMQP method: a client sends a basic.publish on a channel, and does wait for the broker to respond before continuing. �In fact: if all you're doing is publishing messages to the broker, the broker won't send anything to the client unless something goes wrong (this is part of what makes AMQP a high-performance messaging protocol). �Whats more: since the basic.publish is asynchronous, if something goes wrong on the broker, you won't know immediately after publishing (e.g., calling the rabbitmq-c amqp_basic_publish(...) function ). The failure is transmitted as an AMQP method 'at some point in the future' meaning, likely you'll get an error pretty quickly, but you have to be able to deal with the case that it might happen a bit later.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Since rabbitmq-c doesn't have its own thread sitting there dealing with error messages, and the amqp_basic_publish(...) doesn't do any sort of read on the socket from the broker (the return value only indicates an error if there was a failure writing the message to the socket to the broker), you have to check periodically for methods from the broker.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">You do this by using amqp_simple_wait_frame(). �However this can block on a read() on the socket if the broker hasn't sent anything. �The way to get around this is to use amqp_get_sockfd() on the connection object, then use something like select(), amqp_frames_enqueued(), and amqp_data_in_buffer() to detect there is potentially a frame to be read from the broker.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">An example of a library that does this is SimpleAmqpClient:�<a href="https://github.com/alanxz/SimpleAmqpClient/blob/master/src/Channel.cpp#L283">https://github.com/alanxz/SimpleAmqpClient/blob/master/src/Channel.cpp#L283</a>�. It uses publisher-confirms to make the basic.publish method a synchronous process. �If you sift through the ChannelImpl::GetMethodOnChannel() implementation, you can see what needs to be done to poll the socket for frames.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">[1] The AMQP basic.publish method can be made synchronous by enabling publisher-confirms. However, this does come at a performance cost: there is a full network round-trip for each basic.publish.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">HTH</div><div class="gmail_extra">-Alan<br><br>As a personal plug the SimpleAmqpClient library can be found:�<a href="https://github.com/alanxz/SimpleAmqpClient">https://github.com/alanxz/SimpleAmqpClient</a>. It wraps the rabbitmq-c library in a (hopefully) easy-to-use synchronous c++ interface. �Since it uses publisher-confirms and waits for a confirmation before allowing another message to be sent, it won't have the best message publish through-put (I can get 3-4k-msg/s, whereas using unconfirmed messages I've seen as high as 20-25k-msg/s over a single connection).<br>
<br><div class="gmail_quote">On Fri, May 4, 2012 at 3:43 PM, Unni, Monish <span dir="ltr"><<a href="mailto:munni@etrade.com" target="_blank">munni@etrade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for your replies Emile!<br>
<br>
the only thing close to the c-client for basic.return i found this : <a href="https://groups.google.com/forum/#!msg/rabbitmq-discuss/fHL9tQHj4s0/FxCQxx4khKQJ" target="_blank">https://groups.google.com/forum/#!msg/rabbitmq-discuss/fHL9tQHj4s0/FxCQxx4khKQJ</a><br>
not sure if it does the same thing as java-api.<br>
<br>
or if you could link me to github for this functionality.<br>
<br>
kind regards,<br>
-monish<br>
<div class="HOEnZb"><div class="h5"><br>
On May 4, 2012, at 2:33 AM, Emile Joubert wrote:<br>
<br>
> Hi,<br>
><br>
> On 04/05/12 05:19, Unni, Monish wrote:<br>
>> * is it okay to pair request-reply channels and use the same<br>
>> connection to provide "maximum" concurrency?<br>
><br>
> It is okay to send and receive messages on the same connection. Bear in<br>
> mind that if the broker decides to block the connection then all<br>
> channels in that connection will be affected. I'm not sure you will<br>
> achieve higher concurrency this way.<br>
><br>
>> * how can we get this feature working for "C" clients ( C- api ) ?<br>
><br>
> Have you taken a look at the C client examples?<br>
><br>
>> * and last : is my understanding right ( from observation ) that the<br>
>> request channel and reply-channels have to share the same connection<br>
>> for this feature to work?<br>
><br>
> In general requests and their corresponding replies do not have to share<br>
> a connection, but for basic.return to work the return handler must share<br>
> a channel with the publisher.<br>
><br>
> -Emile<br>
><br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">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>
</div></div></blockquote></div><br></div>