qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: how qpid can verify whether message delivered to the receiver
Date Sun, 03 Feb 2013 18:10:03 GMT
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message