You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by mr_deb <de...@gmail.com> on 2013/02/03 18:34:26 UTC
Re: how qpid can verify whether message delivered to the receiver
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
Re: how qpid can verify whether message delivered to the receiver
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi, Sorry I've not got back to you on this.
I'm afraid that I'm a bit rusty on this I'm pretty sure it's in the
x-declare part of an Address String (which I assume you are using to
specify your queue/bindings etc. if you're using qpid::messaging or JMS).
The Address String is specified here
http://qpid.apache.org/books/0.20/Programming-In-Apache-Qpid/html/section-addresses.html,
but I've just looked and the various useful things that can be done in
x-declare aren't specified in that document unfortunately.
There's another document that I dug out of my bookmarks here:
https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP
which contain a number of x-declare options not obviously documented
elsewhere, but I can't see plain old autoDelete mentioned.
I'm "99% convinced" that it's just in the x-declare block of an Address
String Node or Link declare e.g. you'd do something like.
x-declare: {"autoDelete": true} or if you wanted it to be an exclusive
queue you'd do x-declare: {"exclusive": true, "autoDelete": true}
I have a vague recollection that there may have been something odd about
the true and you may have to do x-declare: {"autoDelete": "True"} but I
might have imagined that.
There is also the option of delaying the auto delete:
x-declare: {"autoDelete": true, "qpid.auto_delete_timeout": 60} e.g.
wait 60 seconds after the last connection before deleting.
I must stress that I'm a bit rusty, If I get a moment tomorrow I'll try
them out, but I'm in a bit of a rush this evening I'm afraid.
If Gordon Sim or Rob Godfrey are reading this thread - guys Re: the
x-declare options I thought that there was an intention to unify this
stuff into Programming in Apache Qpid? There have been a lot of good
additions to this of late but I didn't notice anything covering how to
declare auto delete when I skimmed the "Addresses" section. Have I
missed it?
Also to be honest I'm not too clear how x-declare: {"autoDelete": true}
differs from using delete: receiver in an Address String, I don't
usually use autodelete queues.
Cheers,
Frase
On 06/02/13 06:16, mr_deb wrote:
> Thanks for sharing all the options.
>
> I actually want to go with the approach of deleting the queue itself from
> the broker when connection is getting lost. Any way I am creating separate
> queue for each Sender and receiver point to point communication(I hope it
> will not impact any thing in the performance ). So whenever client close
> connection I want to delete the queue itself.
>
> Can you please give me one example how to create auto delete queue.
>
>
>
>
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7588086.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
Re: how qpid can verify whether message delivered to the receiver
Posted by mr_deb <de...@gmail.com>.
Thanks for sharing all the options.
I actually want to go with the approach of deleting the queue itself from
the broker when connection is getting lost. Any way I am creating separate
queue for each Sender and receiver point to point communication(I hope it
will not impact any thing in the performance ). So whenever client close
connection I want to delete the queue itself.
Can you please give me one example how to create auto delete queue.
--
View this message in context: http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7588086.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
Re: how qpid can verify whether message delivered to the receiver
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi,
sorry I didn't get back on this.
Given the behaviour that you're suggesting I'm wondering whether you
care about acks at all? With the C++ qpid::messaging API and JMS it's
possible to configure an Address String with link: {reliability:
unreliable} which says that the consumer application doesn't care about
acking messages.
If this is enabled the client runtime might prefetch some messages which
will take them off the broker queue but the client application might not
yet have processed them, in this scenario if the client process dies
then the messages in the prefetch queue get blatted, but the broker
isn't maintaining any references to them and won't attempt redelivery.
In this scenario the only messages that remain on the broker are those
in the actual queue. It "sounds like" this is the behaviour that you are
after unless I've misunderstood you?
If you actually want to zap everything including the queue you can
create the queue as exclusive and autodelete, in that case the queue
will get removed when the connection to it is removed. If you don't set
it as exclusive but do have autodelete you can have multiple consumer
connections to the queue and the queue will be removed when the last
connection is closed. That sounds more than you want, but it may be
useful to you.
If you *do* still want/need to ack - you say "whenever receiver received
a special type of message Receiver wants to clear all pending messages
dedicated to him " - as I said the other day if you call acknowledge()
on the most recent message received - in your case perhaps the "special"
message, then that will also acknowledge all messages previously
consumed on the Session that message came from - at least that's how JMS
works and I think qpid::messaging too.
HTH,
Frase
On 04/02/13 06:25, mr_deb wrote:
>
> HI
> Actually in my application I have one requirement is whenever a client
> exists properly I want to remove all pending message from the broker which
> are waiting for ack. So that next time when clients comes up it should not
> receive the messages.
>
> Or to elaborate in simplify way whenever receiver received a special type
> of message Receiver wants to clear all pending messages dedicated to him
> from the broker and then it will close connection with broker properly.
>
>
> Hope this time I am clear with my doubts.
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7587914.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
Re: how qpid can verify whether message delivered to the receiver
Posted by mr_deb <de...@gmail.com>.
HI
Actually in my application I have one requirement is whenever a client
exists properly I want to remove all pending message from the broker which
are waiting for ack. So that next time when clients comes up it should not
receive the messages.
Or to elaborate in simplify way whenever receiver received a special type
of message Receiver wants to clear all pending messages dedicated to him
from the broker and then it will close connection with broker properly.
Hope this time I am clear with my doubts.
--
View this message in context: http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7587914.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
Re: how qpid can verify whether message delivered to the receiver
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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
Re: how qpid can verify whether message delivered to the receiver
Posted by mr_deb <de...@gmail.com>.
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 .
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.
--
View this message in context: http://qpid.2158936.n2.nabble.com/how-qpid-can-verify-whether-message-delivered-to-the-receiver-tp7587875p7587910.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
Re: how qpid can verify whether message delivered to the receiver
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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