I was just chatting to a colleague of mine who asked a question that
left me scratching my head and racking my memory.
He was playing with the GUI and commented that he'd created a queue
called test and added a binding to amq.match so he'd selected "any" and
for fun added a binding k=v1 then added another k=v2.
His comment was that only the k=v2 was retained.
It was kind of interesting (TBH I normally use x-match all) but with
"any" it sort of makes logical sense to allow multiple values for a
given key as "any" implies a "logical or" behaviour. However it didn't
surprise me why the GUI behaves like this because internally the
properties are held in a Map and moreover because adding bindings is
done by invoking a QMF method I knew that the QMF arguments were also
passed in a Map.
I've checked with qpid-config on Qpid 0.20 doing:
qpid-config bind amq.match test k1 any k=v1, k=v2
And that results in
Queue 'test'
bind [test] => ''
bind [k1] => amq.match {u'k': u'v2', u'x-match': u'any'}
When I do qpid-config -r queues, which is consistent with what the GUI
displays too, but as recent versions of qpid-config use the QMF2
protocol directly (I believe) that doesn't entirely surprise me.
However my colleague reckons that he thought he'd seen cases where (with
previous versions of Qpid) he'd actually seen k=v1 and k=v2 present.
Unfortunately I don't have Qpid 0.8 anywhere handy on any machines I've
got access to so I can't check this, is anyone else able to?
I'm actually somewhat sceptical about this because older versions of
qpid-config needed to be patched slightly in order to see headers
bindings by showing the bind.arguments e.g. in QueueListRecurse
if bind.arguments:
print " bind [%s] => %s %s" %
(bind.bindingKey, ename, bind.arguments)
else:
print " bind [%s] => %s" %
(bind.bindingKey, ename)
But as bind.arguments is itself a Map I'd have thought that this
wouldn't support multiple values for a given key anyway.
It'd be great if someone was able to prove/disprove that older versions
of Qpid (e.g. 0.8) did/didn't support multiple values for a given key
with x-match any.
As I say I'm sceptical, but it's bugging me now :-) I'm thinking that
he's just thinking of multiple bindings being in place between amq.match
and the test queue but I'd love to be sure......
Grateful for any thoughts on this.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]