>> Can you elaborate a little on the use cases for that behaviour?
The usecase is the following: we have a c++ client (messaging api) working as a
forwarder to a proprietary system.
The receiver looks like this:
Message message;
while(!isStopped())
{
If(receiver.fetch(message, duration))
{
proprietarySystemAdapter.send(message)
}
}
In another thread this proprietary system acknowledges processed messages.
The problem is that some of messages can take rather long time to be processed
and some messages can be processed very fast. What I'd like to achieve is
prevent system overloading with a large amount off messages.
>> There are two questions in my mind. The first is simply how to allow users
>> to specify they want that behaviour in a neat and simple way. The second is
>> more problematic. ...
Currently the receiver has a number of useful methods, such as getAvailable() -
number of messages in the internal queue, getUnsettled() - number of
acknowledged, but not yet confirmed messages
I suppose that if there is a method like getUnacknowledged () - number of
received (by means of Receiver::fetch(...) or Receiver::get(...)), but not yet
acknowledged messages it would be possible to implement such a behavior
(receiving the messages only if there are not more than a predefined number of
unacknowledged ones exist) manually.
Best Regards,
Sergey
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Wednesday, September 19, 2012 2:12 PM
To: [email protected]
Subject: Re: How does the prefetch/receiver capacity really work?
On 09/19/2012 09:28 AM, Zhemzhitsky Sergey wrote:
> Hi Gordon,
>
> Thanks for the answer.
>
> I'm wondering whether there is any possibility to move the prefetch window
> only after a message or a number of messages are acknowledged?
It isn't supported now. Can you elaborate a little on the use cases for that
behaviour?
There are two questions in my mind. The first is simply how to allow users to
specify they want that behaviour in a neat and simple way. The second is more
problematic.
At present for capacity > 1 I use the AMQP 0-10 'window' mode for credit, where
the window is moved by session-completed controls. However messages are
considered completed as soon as they are received by the messaging library. All
that is then needed is to periodically send information about the completed
messages.
However, in this scheme, other actions on the session can result in that
completion information being sent to the broker (which would move the window
forward).
To give a guarantee that the 'prefetch' window moved only when messages are
acknowledged (not just fetched), I would need to change to use explicit
credits. I haven't thought it through in detail but if that turned out to be a
large amount of work, I'd probably argue for dealing with it only on the 1.0
implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
_______________________________________________________
The information contained in this message may be privileged and conf idential
and protected from disclosure. If you are not the original intended recipient,
you are hereby notified that any review, retransmission, dissemination, or
other use of, or taking of any action in reliance upon, this information is
prohibited. If you have received this communication in error, please notify the
sender immediately by replying to this message and delete it from your
computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or
go to www.troika.ru/eng/Contacts/system.wbp
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
