Thanks Ted! ________________________________________ From: Ted Ross [[email protected]] Sent: Tuesday, August 16, 2016 1:17 PM To: [email protected] Subject: Re: C++ Messaging API Question: Receiver Capacity?
On 08/16/2016 02:05 PM, Flores, Paul A. wrote: > 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? No. > > > > 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. > When the capacity is set to 10, the client issues credit to the broker for up to 10 deliveries. The broker then delivers all 6 messages and has 4 credits remaining. If, at this time, more messages arrive on the queue, up to 4 of them will be immediately delivered to the client. As each received message is "fetched", one additional credit is issued to the broker. The important point here is that the receiver doesn't go to the broker for more messages. The messages are pushed from the broker based on available credit. In a fluid situation where messages are constantly flowing from broker to receiver, the local queue may never be empty. In fact, if the queue empties, that represents a stall in flow that adversely affects throughput. > > > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] ________________________________ 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
