Frase,
I think you're mostly correct about the way that qpidtoollibs should
work with regard to object-ids. In QMFv1, the IDs were broker-assigned
and opaque. In v2, they are composed of the values of the referenced
object's "index" properties. This is why the id == name assumption
worked. It might be more correct to do as you suggest and compare to a
properly formed getObjectId() result.
With regard to using the topic exchange for replies, that was quite
deliberate. There's really no benefit to using a different exchange for
replies and it makes writing ACL rules more difficult. It also makes it
more difficult to use any form of federation for exchanging messages. I
would consider deprecating the qmf.*.direct exchanges altogether.
-Ted
On 03/04/2013 04:24 PM, Fraser Adams wrote:
Hi all,
I'm currently in the process of writing a QmfManagementPlugin for the
Qpid Java Broker. This uses the same ManagementPlugin API that the JMX
and REST Plugins use, but as the name suggests is exposing the Java
Broker's internal Management Objects as QMF2 Objects.
I'm making good progress and I've got most of the key objects exposed
and their properties mapped to the same management-schema.xml as the
C++ broker. In other words I'm pretty close to having a unified way of
controlling both the C++ and Java brokers, yippee!!
So far it's all looking great with the Qpid GUI, but I've run into a
couple of issues when testing with qpid-config
The original qpid-config was never going to work 'cause that uses
QMF1, but recently (I think with Qpid 0.18) this got changed to use
QMF2. In theory this should have "just worked", but no :-(
qpid-config queues and qpid-config exchanges work fine, but there's a
problem with the qpid-config -r queues and exchanges.
It was happily listing the queues, but it wasn't trapping the bindings
and I've noticed why....
In qpid-config for Qpid 0.20 in ExchangeListRecurse there's a test:
if bind.exchangeRef == ex.name:
I believe that is wrong, the exchangeRef is a QMF *object reference*
and it should be tested against the exchange's ObjectId and *not* its
name, there is no guarantee that a QMF Object's name and ObjectId are
the same value.
I've just checked with qpid-config for Qpid 0.12 and the same line reads:
if bind.exchangeRef == ex.getObjectId():
I believe that is the correct approach to take. management-schema.xml
says:
<property name="exchangeRef" *type="objId"* references="Exchange"
access="RC" index="y" parentRef="y"/>
In Binding and
<property name="name" *type="sstr"* access="RC" index="y"/>
Clearly using ex.name works with the C++ broker, but I believe that
this is a quirk of a particular implementation choice relating to how
C++ broker ObjectIds are created rather than something that should be
relied upon.
Hmmmm, so I've checked further and looked in broker.py in qpidtoollibs
and there appears to be some bizarre mangling going on. The
QmfConsoleData objects seem to be instances of class
BrokerObject(object): and in:
def __getattr__(self, key):
for some reason if the object property is a Map/dict (as is the case
for exchangeRef/queueRef) it seems to be parsing the _object_name
value out of the dictionary to try to expose the "name" part.
I guess that's why " if bind.exchangeRef == ex.name:" works, but to my
mind that seems to be really evil because it's making an assumption
about the structure of ObjectId, which may or may not hold.
What's more frustrating is that there's also:
def getObjectId(self):
return self.content['_object_id']['_object_name']
But that pulls the complete "_object_name" out of the ObjectId so that
would never match any reference property
(I did actually try hacking qpid-config to do " if bind.exchangeRef ==
ex.getObjectId():") and wondered why that didn't work.
I really think that this is all pretty inconsistent, yeah it works
with the current C++ broker, but I don't think it's right.
As a bit of a hack I tried:
if bind.values['exchangeRef'] == ex.content['_object_id']:
And that works with both the C++ and Java brokers (with my
AgentPlugin) but it's ugly and I think that the original approach of
if bind.exchangeRef == ex.getObjectId():
is by far and a way the most correct way to express this.
Now that I know what the problem is I can clearly change the way I
construct the ObjectIds in the Agent to ensure that the
BrokerObject mangling pulls out the right info, but I really believe
that ObjectIds should be treated as opaque rather than parsed in the
way that has been done in BrokerObject.
While I'm already off on one :-) I think that the BrokerAgent replyTo
in broker.py is a bit weird too. It's defined as:
self.reply_to = "qmf.default.topic/direct.%s;{node:{type:topic},
link:{x-declare:{auto-delete:True,exclusive:True}}}" % \
str(uuid4())
Why on earth would the reply to be bound to qmf.default.topic rather
than qmf.default.direct??? especially given that the binding key is
clearly pointing out that it's a direct address?? It's not such a big
deal as the ObjectId stuff, but I do think it's a bit odd.
Interested to know what others think.
I'll get back in my box now :-)
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
