On 03/01/13 19:18, Ken Giusti wrote:
Hi Fraser,
I think the fix for this bug is to prevent the headers exchange from allowing
multiple bindings with the same keys.
In that case, when entering the following commands:
qpid-config bind amq.match test f1 all k1=v1
qpid-config bind amq.match test f1 any k1=v1
the second qpid-config command would fail (binding already in use).
Yes I agree I think that the second command *should* fail as the
<exchangeName>/<queueName>[/<bindingKey>] combination is the same for
both and it's that combination of names that are used internally. At
least for 0.12 duplicates are accepted without QMF sending an exception
(unlike for adding queues or exchanges where an exception "object
already exists <name>" gets reported by by the invokeMethod response).
I think that - for headers exchanges - the binding key isn't really used
beyond identifying the binding (so you can eventually delete it).
I personally encourage the use of a binding key for the headers
exchange, you are correct that it is optional and it looks as though if
you add a single binding without a key you can actually add it and
delete it, but having an explicit key helps add clarity IMHO - I
generally use descriptive keys that relate to what the binding is trying
to achieve.
So you could get the same behavior doing:
qpid-config bind amq.match test f1 all k1=v1
qpid-config bind amq.match test f2 any k1=v1
instead. At least that is what I remember - it's been awhile. What do you
think?
Yes with different keys it's possible to add an any and an all match,
though the former then becomes redundant.
If you then do
qpid-config bind amq.match test f3 all k1=v1
so basically add a duplicate binding but with a different key it doesn't
get added (silently). I think that not adding it is probably the right
thing to do, but I don't like it silently failing I think an exception
should be sent back.
There's definitely plenty of inconsistency though, I've just tried
adding bindings to an xml exchange, but if I add two bindings with keys
f1 and f2 with the same xquery they get added - this is largely
equivalent to adding headers bindings with the same k/v properties,
which as said above doesn't get added, so that seems inconsistent.
What's even weirder is if I try to add another xml binding with key f1
but with a different xquery that binding doesn't get added (silently)
but I don't get "error Detected two management objects with the same
identifier:" from the broker, which suggests that for the xml exchange
some sort of test is being done on the overall key (unlike the case for
the headers exchange) but an exception isn't being reported back.
Hopefully my Qpid GUI will be in a releasable state in the next couple
of days, I'm currently going through some final bugs & snags and a
little bit of work to get it looking nice on mobile browsers.
Very cool! Have you tried running it against 0.20 release candidate qpidd?
Should work fine, but it's always nice to get extra exposure before we cut the
release.
-K
It's looking pretty good now, it's quite flashy with iOS style animated
page transitions. It's basically a single page web-app using AJAX to
update the state. What I've done is write a Java Qpid REST API bridging
to my QMF2 implementation then on the JavaScript side I've written a QMF
API wrapper to the REST API, so my core JavaScript GUI code actually
talks the QMF2 API.
I did it that way 'cause it provides much cleaner abstraction. At the
moment the bridge is pure REST/HTTP but I might extend that in the
future to use WebSockets, I've not done that yet as a) I've not got much
Web Socket experience and b) it has poorer cross-browser support. At the
moment by GUI runs on everything from IE6 up to modern mobile browsers.
The main bit of styling I've yet to do is to do a bit of "real-estate
adjustment" for small displays like iPhone - it's currently got a
sidebar a la iPad which needs to be hidden on smaller devices. Nearly
there though :-)
I've not tried it with anything later than 0.12 yet. Unfortunately every
time I've upgraded qpid version I've needed to fight the makefile. I
noticed that Gordon Sim has incorporated a patch I did for the makefile
into 0.20 so hopefully that pain will go away shortly. I'll give it a
whirl with 0.20 before I release.
I *hope* nothing breaks. It *should* be OK unless anyone has messed
around with the QMF2 logic??? I recall between 0.8 and 0.10 there was a
change to QMF Events where they started to get sent as AMQP lists from
0.10 unfortunately amqp lists don't map terribly well to JMS and I ended
up using some of Gordon's code that used the low-level AMQP decodes. So
unless anyone has been messing around with mappings from AMQP list to
JMS it should just work.
I'm off to write some more code now :-)
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
