qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flores, Paul A." <PAUL.A.FLO...@SAIC.COM>
Subject C++ Messaging API Question: Receiver Capacity?
Date Tue, 16 Aug 2016 18:05:53 GMT
At Client Site,



An interesting question has come up regarding how setting the receiver's capacity influences
receiver processing.



In one "reading" of the API documentation regarding set capacity an "impression" or "inference"
has been arrived at and I have been asked to either confirm or refute.



The "impression" /"inference" is as follows.



Given:

 1. The queue , "A", has been "instantiated".

 2. Various senders have placed 6 messages onto the queue "A".



A receiver for queue "A" with a capacity of 10 is created.



When a fetch  is performed .  The receiver process "waits" until there are 10 messages on
the broker and when the capacity has been meet loads the messages into a local queue providing
one message to the "caller" for each fetch and goes back out to the brokers to obtain subsequent
messages when the local queue is depleted.



Is this  "impression"/"inference" correct?



I believe that the "impression"/"inference" is incorrect and that the receiver process "obtains"
all 6 messages into a local queue providing one message to the "caller" for each fetch and
goes back out to the brokers to obtain subsequent messages up to the receiver capacity when
the local queue is depleted.



Insights, clarifications and comments are appreciated.



Paul










________________________________

This communication (including any attachments) may contain information that is proprietary,
confidential or exempt from disclosure. If you are not the intended recipient, please note
that further dissemination, distribution, use or copying of this communication is strictly
prohibited. Anyone who received this message in error should notify the sender immediately
by telephone or by return email and delete it from his or her computer.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message