On 4 March 2014 14:11, Gordon Sim <g...@redhat.com> wrote:
> On 03/04/2014 12:38 PM, Rafael Schloming wrote:
>
>> On Tue, Mar 4, 2014 at 6:39 AM, Gordon Sim <g...@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 :-)
>
>
>
I agree with Gordon here. Since the messaging API / address stuff
effectively merged the domain of queue names and exchange names, that
ambiguity has existed. I think it is probably least likely to cause people
issues if we continue to treat ambiguous addresses in the same way.
> 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 be honest I am going to treat the "default" exchange like this... i.e.
it will resolve anything it sees in the routing key of a message sent to it
in the same was the AMQP 1.0 interface will treat an address sent to the
routing node. However this in itself doesn't resolve the ambiguity about
"foo" because where foo routes to is dependent upon whether there is an
exchange, a queue or both. (In practice this may be a small violation of
the 0-x spec as things will route even if the routing key doesn't represent
a queue... however given the broker is opening up all sort of possibilities
for nodes which are no longer queues nor exchanges, I am happy with this
violation).
-- Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
