qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Use of subject for routing - moved thread to user list from earlier private discussion.
Date Fri, 29 Aug 2014 15:15:41 GMT
On 29 August 2014 16:50, Fraser Adams <fraser.adams@blueyonder.co.uk> wrote:

> I guess that from my perspective one of my main concerns is consistency
> between the C++ and Java Brokers (and as much as possible with other
> vendors) without that things get very confusing.
> Another thing I guess that I'd want to make sure gets thought about is how
> this stuff gets mapped to various APIs.
> I think I've got some sympathy with the logic of Rob's comment "subject as
> "A common field for summary information about the message content and
> purpose" " and "The "to" field is defined as "identifies the node that is
> the intended destination of the message" " those sort of definitions seem
> to fit with traditional email interpretations of subject and to, however
> it's very definitely fairly "traditional" in Messaging to use the term
> "subject" when talking about publishing topics i.e. the traditional
> "UK.NEWS" subject, so it's not unreasonable that people might intuitively
> feel that subject and routing key have a relationship.
> Back to my point about APIs though, one thing that I think is important is
> to be able to efficiently "multiplex" messages. In the current subject
> based world I could have a number of consumers to amq.direct called Q1, Q2,
> Q3 etc. and in JMS I could create a simple producer that had "amq.direct"
> as the JMS destination. From my client's perspective I can create that at
> startup time and send different messages to different places just by
> setting the subject.

Except that there is no way to set the subject in JMS, other than through
some Qpid specific magic that doesn't actually exist in any AMQP 1.0 JMS
client to my knowledge :-).  The qpid.subject hack (which then had to be
changed again because qpid.subject is an illegal name in JMS) was an 0-10
Addressing Syntax specific addition to the Qpid JMS client.  You couldn't
use that if you were using AMQP 0-9-1, for instance.

> I wouldn't want to have to create new Destination objects every time that
> I wanted to send a message!! I know that "to" is an immutable AMQP 1.0
> property, but what's the API mapping - and what should it contain??
So, JMS is clearly rubbish in the way that it does topics :-)

> what do I mean "what should it contain??" well different things might make
> different sense depending on whether one is using a "connection-oriented"
> API or not. For example in Messenger I "think" that the to would be the
> whole address - say "amqp://guest:guest@localhost:5673/qmf.default.direct/broker"
> what

The on the wire address should never contain amqp://guest:guest@ .  The
magic of the Messenger API, of course, is a whole different matter.  How a
messenger address is translated to an on the wire address similarly.
 Personally I think that while Messenger is useful for some bootstrapping
cases, for a large scale system you would need to separate your connection
address (where you connect to) and the message address (the logical name
which will be used to determine where the message ends up).  I believe
Messenger can be set up with some sort of routing table to achieve this...
but I think the base case for Messenger misleads as to how addresses would
work in a larger system (addresses are not going to be scoped and bound to
a DNS address of a connectivity endpoint).

> would it be in a connection-oriented API like JMS/qpid::messaging, would
> it be the same or would it just be "broker". We already have this sort of
> strange inconsistency around replyTo where one interpretation of a replyTo
> might be the fully qualified AMQP address of the originator, but the
> Broker's use the node name, both are reasonable interpretations, but they
> are clearly different and have different implications
> Similarly in Messenger, as I say I think that the "to" gets set by
> setAddress() on Message, but I've no idea what caching (if any) takes
> place. Is it more efficient to do something like:
> message.setAddress(address + '/' + subscriptionQueue);
> where subscriptionQueue might be one of the Q1, Q2, Q3 things I mentioned
> above, or is it more efficient to do
> message.setAddress(address);
> and pass the subscriptionQueue information as the subject/routing-key
> whatever.
> So I think it's not just about whether in the AMQP 1.0 spec. the subject
> and to now look more like the email interpretations (and I do have sympathy
> with that view) as I say though it's also about traditional interpretations
> of what "subject" means in messaging systems and also about how the various
> APIs allow multiplexing of messages.
I agree - this is really a question about how we present features through
APIs and how much our current mapping from APIs should drive our broker
models, vs. how an abstract model can be presented through an API.
 Moreover I think it is a question as to how "special" we want dealing with
a broker containing a 0.x model to feel compared to the general case of an
AMQP 1.0 network... and conversely how transparent we can make it for an
0.x client to connect into a messaging network which is actually based on
1.0 (and may contain entities that are neither queues nor exchanges).

My personal view, at a very high level I believe that the simplest way to
do routing is to think of things having a single key which is (the usual
case) for routing.  Further that this key can be considered opaque, is
logical, and may refer to an address space rather than a single logical

In my head I am rewriting every AMQP 0.x exchange + routing-key combination
as the address "exchange/routing-key" in AMQP 1.0 and conversely any AMQP
1.0 address of foo/bar as the "exchange" foo and "routing-key" bar in AMQP
0.x.  This obviously may require the broker to dynamically pretend that
such an entity as "foo" exists, in order to service the requests of an AMQP
0.x client.

-- Rob

> Frase
> On 29/08/14 15:12, Rob Godfrey wrote:
>> So, I think the issue has come about on the Java Broker because I have
>> been
>> trying to move some of the other behaviours to be in line with the
>> upcoming
>> work on management and addressing.  In these cases the "to" field of an
>> AMQP 1.0 message is used for routing purposes.  The inadvertent side
>> effect
>> of the changes (that to was promoted "to" be the primary routing attribute
>> of the message) was that the exchanges which previously used the "subject"
>> field of a 1.0 message where they would use "routing-key" of an 0.x
>> message
>> currently use "to".  Given the way that the legacy filters were
>> constructed
>> this is an error and should probably be changed so that the Java Broker
>> reverts to routing on subject for the amq.direct and amq.topic exchanges
>> (and any other address which in AMQP 1.0 offers the ability to use the
>> legacy filters).
>> In general, however, I think the subject is not the best fit for a mapping
>> of the semantics of the 0.x "routing-key".  The AMQP 1.0 spec defines
>> subject as "A common field for summary information about the message
>> content and purpose", rather than giving it and explicit or implicit
>> routing semantics.  The "to" field is defined as "identifies the node that
>> is the intended destination of the message" which definitely implies some
>> routing semantics but does not make them explicit.
>> If an application is designed around using AMQP 1.0, I would not normally
>> expect them to be putting routing information in the subject field.
>> -- Rob
>> On 29 August 2014 15:55, Fraser Adams <fraser.adams@blueyonder.co.uk>
>> wrote:
>>  All,
>>> I've moved this thread to the user list. It started out on the back of an
>>> email conversation between Rob Godfrey. Gordon Sim and and myself when I
>>> couldn't get my QMF messages routed on the Java Broker.
>>> The original context was that I was sending messages to
>>> qmf.default.direct
>>> and setting the message subject to "broker", this is pretty much exactly
>>> what the python qpid tools such as qpid-config do.
>>> in AMQP 0.10 this works fine because the subject (which in AMQP 0.10 is a
>>> user property called qpid.subject) gets treated as the routing key when
>>> sent to a direct exchange.
>>>  When I did my AMQP 1.0 JavaScript qpid-config port I set the AMQP 1.0
>>> subject (which is now an immutable message property and not an
>>> application
>>> property) to "broker" and sent to amqp://guest:guest@localhost:
>>> 5673/qmf.default.direct
>>> This worked fine with the C++ broker, but with the Java Broker the
>>> message
>>> wasn't routed and in subsequent conversations with Rob and Gordon I
>>> discovered that the Java Broker doesn't route on direct exchanges based
>>> on
>>> Subject rather it first tries to use to "to" - in other words if I sent
>>> to
>>> amqp://guest:guest@localhost:5673/qmf.default.direct/broker it'd work or
>>> if the to isn't set it uses the application property "routing-key".
>>> So basically this thread is around an inconsistency between the C++ and
>>> Java Brokers where the C++ Broker continues to route on Subject for AMQP
>>> 1.0 but the Java Broker does not.
>>> Rob and Gordon can fill in if I've missed anything, but it's probably
>>> best
>>> to share this discussion on the user list.
>>> Frase
>>> On 29/08/14 14:03, Rob Godfrey wrote:
>>>  I think in the context of where AMQP 1.0 is now, routing by subject is
>>>> somewhat counter-intuitive, though when we started we did see the
>>>> subject
>>>> field in a routing-key sort of role.
>>>>   From my perspective I'd say exactly the opposite, that is routing by
>>> subject seems entirely intuitive and is also consistent with what
>>> happened
>>> with AMQP 0.10. Given the use of subject as the defacto routing key on
>>> all
>>> of the python tools I don't think I'm alone in feeling that's intuitive.
>>> I'm pretty sure that the subject is used for routing on topic exchanges
>>> so
>>> I'm not sure why you think its counter-intuitive on derect exchanges?
>>>  In terms of current behaviour - the legacy filters in the Java Broker
>>>> just set up the bindings between the queue and the exchange and thus use
>>>> the same routing as previously described (i.e. they're not currently
>>>> using
>>>> subject). Inside the Java Broker an exchange routes based on an abstract
>>>> notion of the "routingAddress" of a message instance.  In AMQP 0.x
>>>> that's
>>>> taken to be the routing key.  In 1.0 it is as I described in my previous
>>>> mail.
>>>> If we collectively (and this discussion should really be on the users
>>>> list) think that 0.x exchanges should route on subject when routing a
>>>> 1.0
>>>> message then I'm happy to change the default behaviour of the Java
>>>> Broker -
>>>> except for the "no name" exchange which will route on "to" because
>>>> that's
>>>> what we're defining on the addressing spec.  I'll then probably add
>>>> options
>>>> to the exchange implementation so that a user can configure on a per
>>>> exchange basis to route on something else (except for the non default
>>>> amq.*
>>>> exchanges).
>>>> -- Rob
>>>> On 29 August 2014 13:45, Gordon Sim <gsim@redhat.com <mailto:
>>>> gsim@redhat.com>> wrote:
>>>>      On 08/29/2014 11:49 AM, Rob Godfrey wrote:
>>>>          For the moment I guess we'll just have to live with the C++
>>>>          and Java
>>>>          Brokers having different ideas about how to route 1.0 messages
>>>>          at exchanges.
>>>>      The legacy-amqp filters are defined to work on the subject when
>>>>      using the exchange as the source. I thought the java broker
>>>>      supported those?
>>>>      If I create a receiving link from amq.direct with a
>>>>      apache.org:legacy-amqp-direct-binding:string of foo, then send a
>>>>      message to amq.direct whose subject is foo, my expectation would
>>>>      be that the receiver will receive that.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message