On 01/06/2012 10:58 PM, William Henry wrote:
I'm curious about the following: 1) Why do you need to explicitly set the receiver capacity in order to receiver messages? You'd think that be default you'd not have to set this.
You don't. The capacity controls the number of 'prefetched' messages the library will accept, i.e. messages delivered by the broker before - and in anticipation of - application calls to fetch().
The default is to have no prefetch, which means the broker will only deliver a message in response to an explicit fetch() call. The reason for this default is that it gives the most intuitive behaviour in many cases and so is good for exploring/experimenting. (Messages aren't hidden in prefetch queues anywhere).
However, if you are using next_receiver() to service several receivers, then you do need messages to be delivered before you call fetch() (since you don't know which of them will have messages) and so in that case you do need to set capacity to some value greater than zero.
2) Why is exclusive defaulted to true for queues? I'd have thought that the default behavior would be that you could share a queue. And you'd have to specify exclusivity.
Exclusive is set as the default for 'subscription queues', i.e. the queues automatically created when you indicate that you wish to receive messages from an exchange (i.e. when the node is a 'topic' to use the JMS and messaging API terminology, meaning pub-sub).
That seems in general the right default. It is possible to have a non-exclusive subscription queue, but for that you need to specify that is what you want explicitly.
If you create a queue on-demand as the node to which you are sending to- or receiving from-, it will not default to exclusive. In this pattern the queue is more likely to be a shared queue.
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
