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
