qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: AMQP 1.0 <-> 0-10 reply-to conversion
Date Tue, 04 Mar 2014 13:11:01 GMT
On 03/04/2014 12:38 PM, Rafael Schloming wrote:
> On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim <gsim@redhat.com> wrote:
>
>> On 03/04/2014 11:00 AM, Rob Godfrey wrote:
>>
>>> The naive approach for a 1.0 address "foo" is (I guess) to look up on the
>>> broker side to see if the given there is an exchange named "foo" (in which
>>> case translate to 0-10 {exchange="foo", routing-key=""}) or a queue named
>>> "foo" (in which case translate to a 0-10 {exchange="",routing-key="foo").
>>>
>>
>> That is what the c++ broker currently does.
>
>
> In some ways this makes sense, but it also has some undesirable properties,
> i.e. the translation process from 0-10 to 1-0 address form depends on the
> internal state of the broker, and that state may change over time.

It's the translation process from 1.0 to 0-10

> For
> example, say you have a sequence of messages that are initially resolved to
> a queue named "foo", then part way through that sequence someone creates an
> exchange named "foo".

Introducing ambiguity about the node name is I think an explicit 
alteration of the meaning of the name. It would affect the creation of a 
link over 1.0 and even the creation of a sender/receiver using the 
qpid::messaging API over 0-10.

It feels top me in the same class of scenario as deleting and recreating 
a node of a given name (though clearly its not exactly the same and is 
easier to do by accident).

So at present I'm personally inclined not to worry about this too much, 
i.e. consider it a corner case and advise people not to do that :-)

> You now have a mix of live messages some of which
> have address {exchange="", routing-key="foo"}, and others of which have
> {exchange="foo", routing-key=""}. It seems unlikely that the application
> would actually want a single stream of messages all sent to the same
> address to end up with a mix of semantically different addresses when they
> come out the other side of the broker.
>
> One option to consider would be to define a special exchange with a
> reserved name that knows how to interpret 1.0 addresses. That would allow
> you to perform a simple stateless/stable translation of any 1.0 address
> into something like {exchange="$amqp1.0", routing-key="<address>"}. This
> has the benefit that translated address will always have the same semantic
> meaning over time. The one drawback is that the address might not work as
> well with other brokers if they don't recognize the "$amqp1.0" exchange,
> however I suspect if the 1-0 reply-to address is ultimately intended for a
> federated broker, then translating it based on the internal state of its
> current broker is not necessarily the right thing either.

Sounds interesting certainly. My main objective was getting simple 
client-server applications working when the two parties were using 
different protocols (but the same broker). I'm sure more sophisticated 
schemes can be constructed if/when someone has sufficient need and/or 
desire.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message