<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, it's seem OK. rabbitmq server reply NROMAL.<br>
</blockquote>
<br></div>
I don't know librabbitmq that well, but basic.ack is an asynchronous method, so the server can't reply at all. The NORMAL "reply" is presumably being given to you unconditionally by the client library.<div class="im">
<br></div></blockquote><div>The return value from amqp_basic_ack() indicates that the write to the underlying socket was successful, it does not indicate that the call was correct from the broker's point of view. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I check list_consumers. find<br>
that consumer lose. what's the problem ?<br>
</blockquote>
<br></div>
The consumer (and the channel) will have been closed. The server will have reported an error - I'm not sure how you get that in the C API.<br></blockquote><div><br></div><div>The library will indicate a channel error occurred next time a function that reads frames from the broker occurs. e.g., calling amqp_simple_wait_frame() will return a AMQP_CHANNEL_CLOSE_METHOD on the channel you did the invalid amqp_basic_ack(). Note that the broker will only close the channel if an error occurs, it will not positively acknowledge a correct basic.ack. </div>
<div><br></div><div>My recommendation is to add this to your applications processing loop - when you go to read frames from the broker, check for channel.close methods and take appropriate action.</div><div><br></div><div>
-Alan</div></div></div></div>