You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by William Henry <wh...@redhat.com> on 2012/01/06 23:58:58 UTC
Some defaults questions
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.
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.
Best,
William
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Some defaults questions
Posted by William Henry <wh...@redhat.com>.
Ack to both of you. Thnx.
----- Original Message -----
> On Mon, Jan 09, 2012 at 09:40:55AM +0000, Gordon Sim wrote:
> > 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).
>
> One language-specific difference is that, with the non-blocking I/O
> extension for Ruby, the default capacity on a Receiver is 1 rather
> than
> 0.
>
> > 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.
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Some defaults questions
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Mon, Jan 09, 2012 at 09:40:55AM +0000, Gordon Sim wrote:
> 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).
One language-specific difference is that, with the non-blocking I/O
extension for Ruby, the default capacity on a Receiver is 1 rather than
0.
> 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.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Some defaults questions
Posted by William Henry <wh...@redhat.com>.
----- 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:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Some defaults questions
Posted by Gordon Sim <gs...@redhat.com>.
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:dev-subscribe@qpid.apache.org