On 08/05/2014 06:51 PM, Fraser Adams wrote:
Hi Gordon,
I'm aware of the AMQP 1.0 filter stuff, but I'm a little confused by
this post as I was pretty sure that the broker also worked with
"traditional" topic/subject addresses and
<qpid>/cpp/src/qpid/messaging/AddressHelper.cpp translated automagically
to a filter applied to the message source.
That is correct. That translation is done by the qpid::messaging client.
What the broker sees is a link from an exchange, with a filter specified
that describes the desired binding.
[...]
I can also do it explicitly via by specifying the filter in the link
config, e.g.
./drain --connection-options {protocol:amqp1.0} -b localhost -f \
"amq.topic; {link: {name: test-link, filter: {name: 'subject-filter',
descriptor: 'apache.org:legacy-amqp-topic-binding:string', value:
'*.news'}}}"
But as far as I was aware that's just the explicit long hand form of the
first example.
Again, correct.
[...]
if I do:
./recv localhost/#
it's fine and I get a dynamically created queue, and if I have a queue
called test I can do
./recv localhost/test
and it's happy, also if I subscribe to a topic Node e.g.
./recv localhost/amq.topic
That works and I get an automagic subscription queue with a # wildcard
binding e.g.
Queue 'e50b5f02-eeb1-409a-a07f-7ac2c7f06b6c_receiver-xxx'
bind [e50b5f02-eeb1-409a-a07f-7ac2c7f06b6c_receiver-xxx] => ''
bind [#] => amq.topic
However, if I were to do
./recv localhost/amq.topic/*.news
It barfs with:
LINK ERROR (amqp:not-found) Node not found: amq.topic/*.news
My point was that the *broker* could be modified to recognise that an
address of 'amq.topic/*.news' was not just a node name, but a node and a
binding. I.e. that this error could be 'fixed' by changes on the broker
as well as on the client.
[...]
Am I making sense? Basically unless I've totally missed something
Messenger only allows subscriptions to basic Node addresses and doesn't
yet support filters or any other link config. Is that correct?
I believe so, yes. The point I was making however was that the broker
could be modified to recognise binding information passed in the source
*address*, and not in a separate filter on the source. That would work
around the limitations of messenger, but would also be consistent with
what other brokers do at present.
(It wouldn't work for e.g. JMS style selectors of course, which would
still require a filter to be set on the source of the link)
If so it
that on anybody's TODO list? I guess I find it surprising not to be
supported. If it's on nobody's priority
Messenger is certainly not a priority for me. However I am interested in
making the engine API more usable, to the point where it is a reasonable
option for fully asynchronous or reactive applications. I think many
applications can be made quite simple by providing some utilities along
side the engine, without restricting control over the full protocol
where needed.
I might take a look at it when I
get my JavaScript stuff finished off, but equally if anyone is planning
on working on this I'm in no real rush to brush off my C ;->
I'd really appreciate answers to the other questions in my other post
too if anyone happens to know them.
I'll have a go, but bear in mind I could be wrong/out of date.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
