qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Address of default no-name exchange
Date Wed, 29 Jun 2011 10:07:19 GMT
On 06/29/2011 10:38 AM, Jiri Krutil wrote:
>> The default exchange is a direct exchange and the bindings are forced
>> to match exactly with the existing queue names. It is a workaround for
>> the fact that AMQP forces you to send to an exchange whether you want
>> to or not.
>>
>> What is it you actually want to achieve? The only thing you can do by
>> sending messages to the default exchange is send them to a queue (or
>> have them dropped).
>
> A Sender for the default exchange may be useful in case you want to send
> to many different queues using one Sender and a different routing key
> for each message. For instance when sending responses to reply-to queues
> in a request-response pattern.

Ok, I understand. The assumption there is that senders are expensive to 
create?

The reply-to address doesn't have to be a queue of course, to be 
completely generic it should handle any exchange/routing-key pair (at 
least in AMQP 0-10).

> I'm working on a AMQP vendor-neutral C++ API and I'm trying to stay as
> close to the concepts and ideas of the AMQP specs as possible. I guess
> sending to the default exchange is a completely sane thing to do.

Yes, I can see that point of view.

One of the influences on Qpid's messaging API is the 1.0 specification. 
There, to send a message you establish a link to a node on the broker. 
This link is then used for any flow control and for some reliability 
approaches.

My personal opinion is that the default exchange was a slightly clumsy 
workaround for the fact that the versions of AMQP to date restricted 
message 'sinks' to always be exchanges (and message 'sources' to always 
be queues, though that's not related to the default exchange). The lack 
of an explicit relationship between sender and sink was also an issue 
(makes flow control more difficult for example).

The differences between the AMQP versions are significant. An API that 
covers all of them would almost necessarily have to be at a higher level 
of abstraction. That was the approach we took. We felt that the real 
concern of the API was to control the inflow and outflow of messages and 
all that this encompasses, but not to explicitly expose the mechanisms 
as presented by underlying protocol versions.

I'd love to see your API if and when you are ready to publish it!

> Let's say I create a Sender for queue A. It will actually point to the
> default exchange with the routing key defaulting to A, right?

No, the messaging library resolves an address to a particular broker 
entity. If the name matches a queue, then it assumes you want to send to 
the queue. If the name matches an exchange then it assumes you want to 
send to the exchange. If there is both a queue and an exchange with the 
same name then at present you get an error and you have to explicitly 
choose which one you want by indicating the node type in the address.

> What happens if I use this sender to send a message with subject being
> set to B? Will the message go to queue B?

No, it won't.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message