On Tue, Mar 4, 2014 at 8:27 AM, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> 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.
>
The issue isn't the ambiguity. The ability to rewire/reconfigure the
routing behaviour associated with a given address by e.g. adding/removing
bindings is exactly the same sort of "ambiguity", but it is considered a
feature not a bug. The issue is *when* you resolve the ambiguity. With the
messaging API that ambiguity is resolved when a sender/receiver is
established to a given address. A broker implementing some kind of
translation has the choice of whether to resolve it upon link establishment
or on a per message basis. With the reply-to translation, however, you are
adding a new resolution point that has previously never existed. It is
roughly analogous to taking a pure 0-x broker with no translation and
deciding to "pre-route" the reply based on which bindings match the
reply-to as the request goes through the broker rather than based on what
bindings exist when the real reply is submitted.
Now I'm not saying that resolving an address to a node should necessarily
happen on a per message basis like matching against bindings does, but it
does strike me that a clean mapping of 1.0 into an 0-x broker will have to
have well defined address resolution semantics both in terms of *when* that
resolution happens as well as *how* it happens, and that IMHO choosing the
point at which a reply-to passes through the broker isn't a very meaningful
time to perform that resolution. In fact in a federated environment, that
point is pretty much an arbitrary and unknowable point in time between when
the reply-to was first set, and when it is finally used.
>
>
>
>
> > 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).
>
Since you're so close already, why not at least provide the option to
always use this exchange for reply-to conversion? Is there some drawback
I'm missing?
--Rafael
