qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Use of subject for routing - moved thread to user list from earlier private discussion.
Date Fri, 29 Aug 2014 17:10:44 GMT
On 29/08/14 16:15, Rob Godfrey wrote:
> On 29 August 2014 16:50, Fraser Adams <fraser.adams@blueyonder.co.uk> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message