Interesting. This would be good data to have in the docs for the address
string format, along with some more examples for topic exchanges. Maybe in
this case I should use the old client API for declaring the exchange, queue,
and binding, and then subscribe to it with the messaging API. That's hideous,
but it'll work.
I don't mean for the rest of this to be a rant, but if you're looking for
feedback on the new API, here it is.
I found it confusing and difficult to use the new messaging API is because it
has new terminology for existing concepts (e.g. node, link, subject, x-declare,
x-bindings) that I already understood, as well as the difficulty I had in
trying to figure out exactly what the node and link concepts represented. The
fact that they represent different concepts (based on inferences from your
explanation) is only more confusing. At first glance the messaging API looks
really sweet and easy to use, but after digging into it, it's actually harder
to figure out and use than the old client API. This goes all the way down to
the fact that I skipped over the x-declare and x-bindings bits of the
documentation because of the "x-" in their names; I thought they referred to
special xml magic. The fact that I can specify exclusive flags at more than
one place in the addressing scheme tells me it's broken. There should be one
way to do things and it should make sense, and the user shouldn't have to dig
down into the unit test code or the API source code to figure it out.
Using the addressing API to create a queue on a topic exchange would have been
very, very easy if it looked like this:
qpid::messaging::Connection connection;
connection.open("localhost", 5673);
qpid::messaging::Receiver receiver = connection.createReceiver("/vhost;
exchange: { name: 'test', type: topic, durable: false, passive: false,
auto-delete: true }, queue: { name: 'all_foo', passive: false, durable: false,
auto-delete: true, exclusive: false, bindings: [ { exchange: 'test',
routing_key: 'foo.#' } ] }");
qpid::messaging::Message message;
while (receiver->getMessage(message, timeout))
messages_received++;
Very simple, very straightforward, easy to implement. I could even look at the
AMQP spec to see the valid options.
On Apr 26, 2011, at 2:30 AM, Gordon Sim wrote:
> On 04/25/2011 07:32 PM, David Hawthorne wrote:
>> What is the difference between the values give in the node x-declare block
>> and the link x-declare block? They both refer to values used in
>> queueDeclare, but it seems like they are not equivalent.
>
> The 'node' is the primary broker entity of interest, usually the rendezvous
> point between senders and receivers. The 'link' is the association between
> senders/receivers and that node.
>
> In the case of a 'topic' the node is an exchange and the receivers link
> involves a subscription queue that is bound to that exchange and a
> subscription to that queue.
>
> Therefore in this case the x-declare in the node block will control the
> declaration of the exchange (if necessary), while that in the link block will
> control the subscription queue that is bound to the exchange.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
