On 11/02/2011 03:53 PM, Wisler, Trina wrote:
That is very interesting. I was not aware of this behavior. We are using all
default setting for everything other than trying to implement the ring queues
for the declareQueue call (again, very simple example just trying to test
behavior).
Thank you for your replies. I am interested in this buffering behavior in
terms of buffering limits (how many messages get buffered, if there are setting
that I can change that would affect this, etc.).
If you are able to switch to the qpid::messaging API, that is in my view
much simpler and more powerful. (For an overview have a look at the
guide: http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/).
However, even in the qpid::client API you can control the in-flow of
messages for your subscription.
Have a look at SubscriptionSettings, and instance of which can be passed
to the SubscriptionManager::subscribe() call. You can set a prefetch
window, and this will restrict the number of messages that the broker
will deliver ahead of those that you actually process.
E.g.
subMgr.subscribe(listener, "my-queue",
SubscriptionSettings(FlowControl::messageWindow(10)));
which would set a prefetch of 10 messages.
In your experiment this would still mean you could receive up to twenty
messages as 10 could be prefetched while you were not processing them.
If you need to not receive any without cancelling the subscription you
can start with a window of 0 or you can call Session::messageStop()
passing in the name of your subscription (Subscription::getName()). You
can use the Subscription::setFlowControl() to reopen the window.
Hope this helps.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
