On 07/30/2012 11:55 AM, Zhemzhitsky Sergey wrote:
Could you shed some light on what is the difference between Receiver::get and Receiver::fetch when using qpid messaging API?
The fetch() call is in essence a get() call that will do a roundtrip to the server if the timeout is reached with no message available to return, to verify there really is no message at that point.
The get() call on its own would simply return at that point. If the duration is infinite, there would be no difference between the calls.
According to the documentation Receiver::get retrieves a message from this receivers local queue and Receiver::fetch will check with the server that there is no message. What is receiver’s local queue and how it should be used?
Its just the internal queue of message received, awaiting a fetch() call. Other than setting the capacity for the receiver, you don't really use it directly.
What’s is the best way from the point of view of performance to create a queue subscriber that will poll the queue continuously?
If you have a fetch() in a loop, the the timeout will dictate the frequency of polling. A smaller timeout means more polling. However the call will return after the timeout whether or not a messages if found, hence the need to loop.
In my view though, there is little advantage in general to such polling unless there is some value for application to know whether there is a message available at some frequency/interval. The more you poll, the more load you put on the broker. So unless there is a reason for needing more polling, I would set the timeout to the maximum delay acceptable, i.e. the time at which if no message is available you perhaps want to warn about it and/or give up.
Hope this helps, I'm not entirely sure if I'm answering the question... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
