On 29/08/14 16:15, Rob Godfrey wrote:
On 29 August 2014 16:50, Fraser Adams <[email protected]> wrote:
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.
This sort of thing is exactly why I said that it's really important to
consider the APIs and to hopefully try to consider all the various APIs,
because they all have different quirks/strengths/weaknesses - remember
me suggesting that lists probably weren't a good idea in AMQP 1.0
Management 'cause lists are a pain in the butt with JMS (though dead
easy with my JavaScript Messenger ;->).
TBH I'm quite glad this subject (heh, heh, heh) has come up, it's a good
time to get this sort of discussion in the open, as I said earlier one
of the things I'm keen on is the maximum consistency across the Qpid C++
and Java offerings. if we can't do that then we're probably not setting
the best example in terms of cross-vendor interoperability.
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 :-)
It's pretty pants at handling lists too and MapMessage needs an
alternative that plays better with Collections etc. etc. etc. in
fairness I've still got a bit of a soft spot for JMS, but it's quite
irritating too.
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
That's not an unreasonable mental model, but such a model isn't
universally supported at present and there's the potential ambiguity
over whether an address that *looks like* "exchange/routing-key" is
*really* that or a node called "exchange/routing-key", which is equally
valid and
Indeed using an address of that form in Messenger to the C++ Broker
causes it to barf
./qpid-config.js -r queues
amqp://guest:guest@localhost:5673/qmf.default.direct/broker
LINK ERROR (amqp:not-found) Node not found: qmf.default.direct/broker
I've also just managed to add a queue called "exchange/routing-key" :-)
and another called "amq.direct/routing-key"
probably not a good idea, bit it's arguably perfectly valid as an AMQP
1.0 node name.
All this routing stuff is just a wee bit subtle, especially when you
factor in all the various API quirks.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
