On 07/31/2012 10:33 AM, Zhemzhitsky Sergey wrote:
So there is no difference between get() and fetch() if the capacity is
specified and it is greater than zero?
There is, but it is quite subtle and likely not that relevant in most
cases, at least where the timeout is also non-zero.
If you have a non-zero capacity and after the timeout ends there is no
prefetched message available, get() will give up return without a
message. There could however be a message 'on the way'. just pushed out
by the server but not arrived at the client at that point. In the same
circumstance fetch() would do one final check on the broker. So with
fetch() you would know that at the time the timeout expired there really
was no message on the queue.
In most cases this isn't that interesting, but to try and illustrate the
difference, imagine a rather contrived example where you do a
synchronous send() to a queue, then immediately call get() for a
receiver on that queue (whose capacity is greater than zero).
Whether get() returns a message will depend on the timeout specified and
the time it takes the broker to actually push out the message. If you
called fetch() instead, it would always return the message (assuming no
one else sneaked in to take it), regardless of the timeout or the time
taken for the broker to actually push it out.
Generally I would say use fetch() and if you want prefetch for greater
efficiency set the capacity to a non-zero value. It may have been a
mistake on my part to expose get().
I'm able to get messages without any calls to fetch(), i.e.
string addr("test-queue/test-subject;{create:always,node:{type:queue}}");
Connection connection("amqp:tcp:localhost:5672", "{username: guest, password:
guest}");
connection.open();
Session session = connection.createSession("sessionId");
Sender sender = session.createSender(addr);
sender.send(Message("Hello World!"), true);
session.sync(true);
Receiver receiver = session.createReceiver(addr);
receiver.setCapacity(1);
Message message;
Duration duration(1000);
if(receiver.get(message, duration)) {
cout << "Get: " << message.getContent() << endl;
session.acknowledge(true);
}
Best Regards,
Sergey
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Tuesday, July 31, 2012 1:18 PM
To: [email protected]
Subject: Re: What's the difference between Receiver::get and Receiver::fetch
On 07/31/2012 09:32 AM, Zhemzhitsky Sergey wrote:
I have recently found that Receiver::get does not return anything if the
receiver's capacity is not specified (i.e. zero) and if the receiver's capacity
is greater than 0, then Receiver::get retrieves messages from the broker.
At the same time Receiver::fetch always retrieves messages from the broker even
if the receiver's capacity is not specified.
Is this an expected behavior?
If the capacity is zero there is no prefetch, and get() currently simply
returns any prefetched messages (if they exist). On th eother hand, every
fetch() call will pull off a message if there is no prefetch buffer to take one
from.
Does that make sense?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
