You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2013/02/28 20:37:54 UTC
headers bindings x-match any and multiple values for a given key
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: headers bindings x-match any and multiple values for a given key
Posted by Andy Goldstein <an...@redhat.com>.
Please see http://mail-archives.apache.org/mod_mbox/qpid-users/201112.mbox/%3c4ED91581.108@redhat.com%3e. It's possible there was a bug in the past that resulted in multiple values for the same key being displayed. But Gordon's answer makes sense, from an implementation perspective - a key in a map can only have a single value.
Andy
On Feb 28, 2013, at 2:37 PM, Fraser Adams wrote:
> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org