Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It really depend of what are you trying to do. If you want to get only one message from queue (first one) you probably should use <code>basic.get</code>, if you are planning to process all incoming messages from queue - <code>basic.consume</code> is what you want.</p> <p>Probably, it is not platform or library specific question but rather protocol understanding question. </p> <p><strong>UPD</strong></p> <p>I'm not familiar with it go language well, so I will try to give you some brief on AMQP details and describe use cases.</p> <p>You may get in troubles and have an overhead with <code>basic.consume</code> sometimes:</p> <p><strong>With <code>basic.consume</code> you have such workflow:</strong></p> <ol> <li>Send <code>basic.consume</code> method to notify broker that you want to receive messages <ul> <li>while this is a synchronous method, wait for <code>basic.consume-ok</code> message from broker</li> </ul></li> <li>Start listening to <code>basic.deliver</code> message from server <ul> <li>this is an asynchronous method and you should take care by yourself situations where no messages on server available, e.g. limit reading time</li> </ul></li> </ol> <p><strong>With <code>basic.get</code> you have such workflow:</strong></p> <ol> <li>send synchronous method <code>basic.get</code> to broker <ul> <li>wait for <code>basic.get-ok</code> method, which hold message(s) or <code>basic.empty</code> method, which denote situation no message available on server</li> </ul></li> </ol> <p><em>Note about synchronous and asynchronous methods:</em> synchronous is expected to have some response, whether asynchronous doesn't</p> <p><em>Note on <code>basic.qos</code> method <code>prefetch-count</code> property:</em> it is ignored when <code>no-ack</code> property is set on <code>basic.consume</code> or <code>basic.get</code>.</p> <p>Spec has a note on <code>basic.get</code>: "this method provides a direct access to the messages in a queue using a synchronous dialogue that is designed for specific types of application where synchronous functionality is more important than performance" which applies for continuous messages consumption.</p> <p>My personal tests show that getting in row 1000 messages with <code>basic.get</code> (0.38659715652466) is faster than getting 1000 messages with <code>basic.consume</code> one by one (0.47398710250854) on RabbitMQ 3.0.1, Erlang R14B04 in average more than 15%.</p> <p>If consume only one message in main thread is your case - probably you have to use <code>basic.get</code>. </p> <p>You still can consume only one message asynchronously, for example in separate thread or use some event mechanism. It would be better solution for you machine resource sometimes, but you have to take care about situation where no message available in queue.</p> <p>If you have to process message one by one it is obvious that <code>basic.consume</code> should be used, I think</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload