From users-return-7653-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Sun Feb 3 18:10:47 2013 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 009C6EC16 for ; Sun, 3 Feb 2013 18:10:47 +0000 (UTC) Received: (qmail 24617 invoked by uid 500); 3 Feb 2013 18:10:46 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 24594 invoked by uid 500); 3 Feb 2013 18:10:46 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 24585 invoked by uid 99); 3 Feb 2013 18:10:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Feb 2013 18:10:46 +0000 X-ASF-Spam-Status: No, hits=1.3 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk designates 81.103.221.49 as permitted sender) Received: from [81.103.221.49] (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Feb 2013 18:10:39 +0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.2]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130203181017.HJDG1579.mtaout03-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Sun, 3 Feb 2013 18:10:17 +0000 Received: from [82.33.33.147] (helo=[192.168.1.103]) by know-smtpout-1.server.virginmedia.net with esmtpa (Exim 4.63) (envelope-from ) id 1U240z-0004Y4-CL for users@qpid.apache.org; Sun, 03 Feb 2013 18:10:05 +0000 Message-ID: <510EA7FB.1030102@blueyonder.co.uk> Date: Sun, 03 Feb 2013 18:10:03 +0000 From: Fraser Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: how qpid can verify whether message delivered to the receiver References: <1359734482994-7587875.post@n2.nabble.com> <1359912866695-7587907.post@n2.nabble.com> In-Reply-To: <1359912866695-7587907.post@n2.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=AUhbpHVS+xhHrj9wLCYAQoYnFLYUZdbP8UM0GmH2jwk= c=1 sm=0 a=D6wcrpBcUpcA:10 a=AbTzs2Y0TBQA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=9I5xiGouAAAA:8 a=mV9VRH-2AAAA:8 a=zjgbuafqqkpO-rKZorYA:9 a=wPNLvfGTeEIA:10 a=ZSrn00Koi_IA:10 a=2fPOlPt4dusA:10 a=t4mir6jhdoWtVOID:21 a=nOnP5n-uWlzlf0Iy:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Virus-Checked: Checked by ClamAV on apache.org 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