Hello,
One thing to bear in mind is that Qpid (at least using AMQP 0.10) is a
centralised/client-server architecture. What I mean by that is that a
producer client has a relationship with the message broker (conceptually
a server) and a consumer client has a relationship with the broker, but
the producer client and consumer client don't have a relationship with
each other at the basic messaging layer you have to conceptually have
some application level logic to make that so.
In Qpid producers publish messages to exchanges and consumers receive
messages off queues and if there's an appropriate binding between the
exchange and the queue the consumer will eventually be able to consume
the message.
So what that means in your context is that setting send to be
synchronous merely means that the send method will block until the
broker has accepted responsibility for the message, this does not have
anything to do with consumer acks.
A consumer ack tells the broker that the client application has received
the message and is finished with it so once acked if the consumer were
to die and come back up again it won't have that message resent by the
broker - only unacked messages get redelivered to consumers.
I have to admit that I don't know of a way for a producer to know that a
receiver has acked a given message, I'm not even sure that's possible
given that the relationship is client-server rather than peer to peer.
That said you say that you are writing a program to measure round trip
latency, so one obvious approach is to use a request/response style pattern.
In this you'd set a replyTo address in the message that you send from
the producer and the consumer would be able to get the replyTo from the
message it receives and fire a message back down to the producer on the
replyTo.
You can do a synchronous request/response where you might call receive()
that blocks until the response for the message returns, or you could do
an asynchronous request/response and set a correlationId you could then
asynchronously fire off a bunch of messages storing their create
timestamp in a map keyed by correlationId and have a MessageListener
getting the looped back response messages you could then key the
original timestamp by using the looped back correlationId and get the
time difference.
That should give a pretty good mechanism for pure round trip latency.
You could also get the consumer to add the timestamp when it actually
received the Message so you could work out any difference between
producer->consumer and consumer->producer times.
HTH,
Frase
On 03/02/13 17:34, mr_deb wrote:
Hi
I am writing qpid test program to measure round trip latency. I am sending
message using send api and also sending as synchrnous . But i can see send
function is not waiting whether receiver sent ack or not. I want to know
when message is delivered to the destination. Can you please suggest how to
do that.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7587907.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
