Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 81.103.221.48 as permitted sender)
Message-ID: <510EBB7F.4020204@blueyonder.co.uk>
Date: Sun, 03 Feb 2013 19:33:19 +0000
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
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>
 <510EA7FB.1030102@blueyonder.co.uk>
 <1359916272031-7587910.post@n2.nabble.com>
In-Reply-To: <1359916272031-7587910.post@n2.nabble.com>
Content-Type: multipart/alternative;
 boundary="------------070603080004040908010707"

--------------070603080004040908010707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/02/13 18:31, mr_deb wrote:
> Thanks for your detail explanation
>
> I agree with your request reply approach to measure round trip latency. I
> dont want to add timestamps  when consumer receives the message as producer
> and consumer can sit in two different in system and their timestamps may not
> in synchronous .
That sounds fair enough, do they both get their time via NTP? That might 
get them synchronous enough for you if you're interested in that figure. 
There's an interesting article on NTP accuracy here.

http://stackoverflow.com/questions/97853/whats-the-best-way-to-synchronize-times-to-millisecond-accuracy-and-precision-b

>
> I have one more doubt is there any way where I can see I want to remove all
> message from the broker which are pending for ack.
I'm afraid that I'm not quite sure what you're asking here.

As far as I'm aware calling ack should achieve what I *think* you are 
asking. At least with JMS calling acknowledge() on a Message actually 
acknowledges every message consumed to date on a Session.

"

void*acknowledge*()
                  throwsJMSException  <http://docs.oracle.com/javaee/5/api/javax/jms/JMSException.html>

Acknowledges all consumed messages of the session of this consumed message.

All consumed JMS messages support the |acknowledge| method for use when 
a client has specified that its JMS session's consumed messages are to 
be explicitly acknowledged. By invoking |acknowledge| on a consumed 
message, a client acknowledges all messages consumed by the session that 
the message was delivered to.

Calls to |acknowledge| are ignored for both transacted sessions and 
sessions specified to use implicit acknowledgement modes.

A client may individually acknowledge each message as it is consumed, or 
it may choose to acknowledge messages as an application-defined group 
(which is done by calling acknowledge on the last received message of 
the group, thereby acknowledging all messages consumed by the session.)

Messages that have been received but not acknowledged may be redelivered.

"

I can't say for sure that this behaviour is the same on the 
qpid::messaging C++ API, but it wouldn't surprise me as I think there's 
quite an intentional synergy between qpid::messaging and JMS.


It's worth bearing in mind some subtleties with Qpid. Qpid is often used 
with "prefetch" enabled on the consumer side. If you're using JMS that 
will be the default, if using qpid::messaging then it's disabled by 
default, you need to call setCapacity() on the receiver to enable 
message prefetch.

You asked about "remove all message from the broker ". So bear in mind 
on the broker there will be messages held in the queue, these should be 
removed when messages are consumed by the client - but that'll be the 
client runtime not necessarily the client application so the messages 
might have been put on the client's prefetch "queue". Until messages are 
explicitly (or implicitly if auto acknowledge is enabled) by the client 
*application* the broker must retain references to the messages (even 
though they are no longer in the queue). Because if they haven't been 
acknowledged and the client fails, when it comes back up again 
unacknowledged messages get redelivered.

Regards,
Frase


--------------070603080004040908010707--