----- Original Message ----- > 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.
Do you think there ought to be a way to set the capacity be default for the multiple receiver example? Perhaps set it on the next_receiver call on the session? Or on the session itself. William > > > 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] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
