You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2015/02/02 16:13:34 UTC
Is getAvailable() always 0 when capacity is 0?
Hi,
The question is in the subject, really. To elaborate a bit, I'm talking
about receiving AMQP-0.10 messages via qpid::Messaging::receiver in C++.
Am I right to assume that getAvailable() only counts the messages
already in the receiver, meaning that it must have a non-0 capacity for
a meaningful output value?
I'm debugging an issue with an application where I've forgotten to call
setCapacity(), or failed to realise at the time that I should use that
method, if you know what I'm saying...
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Is getAvailable() always 0 when capacity is 0?
Posted by Gordon Sim <gs...@redhat.com>.
On 02/05/2015 02:28 PM, Toralf Lund wrote:
> On 02/02/15 16:21, Gordon Sim wrote:
>> The capacity controls the number of 'pre-fetched' messages, i.e.
>> messages sent by the broker (or peer) in anticipation of subsequent
>> fetch() calls.
> When exactly are message pre-fetched?
When the capacity of the receiver is set to a non-zero value, that
number of credits are issued to the broker. Its then at the brokers
discretion when they send messages to use up the credit (or indeed
whether they have any messages to send). The broker cannot send more
than the number of credits allocated though. (If the queue has
sufficient messages, the broker will usually immediately send the full
number of messages).
When a message is returned to the application, the library can issue one
more credit - i.e. it slides the prefetch window forward - however it
doesn't necessarily send this immediately to the broker, there is often
some level of batching and it only sends it if its sending something
anyway or if it has some level of outstanding credit.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Is getAvailable() always 0 when capacity is 0?
Posted by Toralf Lund <to...@pgs.com>.
On 02/02/15 16:21, Gordon Sim wrote:
> On 02/02/2015 03:13 PM, Toralf Lund wrote:
>> The question is in the subject, really. To elaborate a bit, I'm talking
>> about receiving AMQP-0.10 messages via qpid::Messaging::receiver in C++.
>> Am I right to assume that getAvailable() only counts the messages
>> already in the receiver, meaning that it must have a non-0 capacity for
>> a meaningful output value?
>
> Correct.
OK. Thanks.
>
>> I'm debugging an issue with an application where I've forgotten to call
>> setCapacity(), or failed to realise at the time that I should use that
>> method, if you know what I'm saying...
>
> The capacity controls the number of 'pre-fetched' messages, i.e.
> messages sent by the broker (or peer) in anticipation of subsequent
> fetch() calls.
When exactly are message pre-fetched?
>
> By default it is 0, meaning that messages are never sent prior to a
> fetch() but only in response to an explicit fetch(). The thinking
> behind this choice of default is that it led to more intuitive
> behaviour, but it's always hard to guess what is intuitive and its
> certainly subjective.
Certainly.
The setup as such seems sort of intuitive to me, too, but what I didn't
really get at first was the relationship between pre-fetch and methods
like getAvailable() and Session::nextReceiver(). Maybe a clarification
in their documentation might be useful. Although when I read it now, it
seems quite obvious that it refers to pre-fetched data. ;-)
- Toralf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Is getAvailable() always 0 when capacity is 0?
Posted by Gordon Sim <gs...@redhat.com>.
On 02/02/2015 03:13 PM, Toralf Lund wrote:
> The question is in the subject, really. To elaborate a bit, I'm talking
> about receiving AMQP-0.10 messages via qpid::Messaging::receiver in C++.
> Am I right to assume that getAvailable() only counts the messages
> already in the receiver, meaning that it must have a non-0 capacity for
> a meaningful output value?
Correct.
> I'm debugging an issue with an application where I've forgotten to call
> setCapacity(), or failed to realise at the time that I should use that
> method, if you know what I'm saying...
The capacity controls the number of 'pre-fetched' messages, i.e.
messages sent by the broker (or peer) in anticipation of subsequent
fetch() calls.
By default it is 0, meaning that messages are never sent prior to a
fetch() but only in response to an explicit fetch(). The thinking behind
this choice of default is that it led to more intuitive behaviour, but
it's always hard to guess what is intuitive and its certainly subjective.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org