Thanks very much for the response Gordon, and your reply to my other
questions.
I realised that it was qpid::messaging that was translating the subject
for to the filter, but I *totally* hadn't got that you were meaning that
the broker could infer that from the address too, thanks for spelling it
out :-)
That seems to make sense given the other brokers that you cite, clearly
consistency is a good thing, though I still think lack of client side
support for this sort of thing is a weakness of Messenger, I surely
can't be the only person who uses non-trivial link specifications?
On the subject of consistency though I guess that another quirk is the
slightly different interpretations that one could get when using
Messenger style addressing talking to a broker or peer-to-peer. What I
mean is that If I were to do
./recv localhost/amq.topic/*.news
With your suggestion the broker would interpret that as an address to
the node amq.topic with the subject filter *.news. That makes logical
sense given most peoples' experience of topics I think.
But say I had a topic exchange called simply topic and a really simply
non-wildcarded subject
./recv localhost/topic/news
How is that address interpreted? Now I suspect that as the broker would
know the topic node is a topic exchange you could still make the
inference, but there is a bit of ambiguity around topic/news as it could
equally refer to a node called "topic/news". I guess that in this
scenario you'd first check for the node "topic/news" and if that didn't
exist check that topic was a topic exchange and if so then apply the
filter? I wonder what if there was for some bizarre reason a queue
called topic too then there would be real ambiguity as you could in
theory apply the filter to the message source from either node.
I'm probably over analysing it :-) the suggestion makes sense I just
struggle a bit sometimes with some of the Messenger/Messaging address
interactions.
On that topic (pun!) I still struggle a little with reply-to, we've had
a conversation around this before but it has got a little more concrete
in my mind now. So I was doing a QMF request/response (I posted on that
a week or so back) now I got my dynamic reply-to stuff working, but it
has struck me that I needed to have a queue created on the broker in
order to receive the reply when in practice my messenger address was a
perfectly reasonable place to send the reply to, in other words I didn't
"need" to have the queue if the broker had respected my fully qualified
amqp address as a reply to.
It's not a big deal, I ended up getting the subscription address and
extracting the dynamic queue name to use as a reply-to, but it struck me
that in an AMQP 1.0 world where brokers are optional and a topology
might have a mixture of routers, brokers and simple AMQP 1.0 containers
being able to honour a reply-to that is a fully qualified address rather
than a broker node name might be useful.
Frase
On 05/08/14 21:22, Gordon Sim wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
