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. 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??
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 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.
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 <[email protected]> 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 <[email protected] <mailto:
[email protected]>> 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: [email protected]
For additional commands, e-mail: [email protected]
