Hi Fraser, >I expect I'm probably pushing the bounds of QMF with this stuff, though >if I do: > >qpid-config bind amq.match test f1 all k1=v1 >qpid-config bind amq.match test f1 any k1=v1 > >I don't get any errors from qpid-config, but the broker says > >2013-01-02 14:49:39 error Detected two management objects with the same >dentifier: >-1543-1--138(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f1)
This appears to be a bug in the way the amq.match (Headers Exchange) is implemented. The exchange+queue+binding-key need to be unique - QMF uses that tuple as the mgmt object index. However, it seems the Headers Exchange also considers the header configuration (k1=v1, etc) when it checks for existing bindings. In the above case, since the header values are different, the exchange creates two bindings even though the exchange+queue+binding key are the same. That's a bug. Gordon hit this bug awhile ago while using federation - https://issues.apache.org/jira/browse/QPID-3356. The other problem - the hang - is probably related: QMF's handling of duplicate object errors has been improved quite a bit since 0.12, but since the problem is rarely hit there are probably still bugs in it. -K ----- Original Message ----- > Hello all, > I've been testing out the add binding functionality on the Qpid UI > I've > been writing and came across some "exciting" broker behaviour :-) > > In précis I was fairly randomly adding and deleting bindings, which > ultimately result in QMF create/delete calls with type of binding. > Eventually I noticed in my UI that I wasn't seeing new bindings being > added. I checked in another instance on another machine (one was from > my > iPad, the other my laptop) and noticed I'd stopped getting QMF > updates. > > I restarted the REST Server that serives the GUI AJAX calls as this > contains the QMF Console instance and that didn't help so it looks > like > it was more an issue with the broker, sure enough when I checked the > broker log I saw. > > 2013-01-01 19:46:26 error Detected two management objects with the > same > identifier: > 0-1541-1--3452(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f3) > 2013-01-02 12:44:07 error Detected two management objects with the > same > identifier: > 0-1541-1--3557(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f2) > 2013-01-02 12:46:09 error Detected two management objects with the > same > identifier: > 0-1541-1--3559(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f1) > 2013-01-02 13:51:15 error Detected two management objects with the > same > identifier: > 0-1541-1--3655(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f1) > > > Restarting the broker fixed things, but this looks like some > defensive > logic is missing on the broker QMF create call (I've been testing > against qpid 0.12). > > If I try adding queues or exchanges with a name that already exists I > get an exception sent back from QMF along the lines of "object > already > exists: amq.match" so there's definitely some defensive logic, so > this > appears only to be a problem with create binding. > > > Unfortunately I only came across this as I was fairly randomly adding > and removing bindings so I can't systematically reproduce this > behaviour > yet. > > I did add a binding between my test queue and amq.match with a > binding > key of f1 and x-match all, when I tried again with x-match any QMF > accepted this without an exception but I got > > 2013-01-02 14:18:41 error Detected two management objects with the > same > identifier: > 0-1542-1--45(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f1) > > > From the broker, but this time I didn't get QMF hanging on me as I'd > had before so it's definitely a bit weird. > > > For create binding the QMF identifier (name) is of the form > <exchangeName>/<queueName>[/<bindingKey>] so as I was able to add > amq.match/test/f1 twice - once with properties {x-match: all} the > other > with {x-match-any} it looks like the test for duplicate names that's > in > place for create queue and create exchange isn't present for create > binding. > > Another slightly odd thing that I noticed in all this is that after > adding and removing a bunch of bindings between amq.match and the > test > queue it looks like the bindingCount property of amq.match is being > incorrectly maintained, it's reporting a value of 6 when I've ended > up > with none. This looks like a discrepancy between the value reported > in > the exchange object's bindingCount property and the actual number of > binding Management Objects that have associations with the exchange > in > question. > > > I expect I'm probably pushing the bounds of QMF with this stuff, > though > if I do: > > qpid-config bind amq.match test f1 all k1=v1 > qpid-config bind amq.match test f1 any k1=v1 > > I don't get any errors from qpid-config, but the broker says > > 2013-01-02 14:49:39 error Detected two management objects with the > same > identifier: > 0-1543-1--138(org.apache.qpid.broker:binding:org.apache.qpid.broker:exchange:amq.match,org.apache.qpid.broker:queue:test,f1) > > > Again though I've not yet been able to reproduce the case where it > really gets its knickers in a twist and becomes dead to other QMF > requests. I'll update this post if and when I manage to break it > systematically, but in the mean time it definitely looks like there's > at > least some weirdness going on with adding bindings. > > Regards, > Frase > > > > > > > > > > --------------------------------------------------------------------- > 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]
