qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject The new QMF2 qpid-config appears to have some "quirks"
Date Mon, 04 Mar 2013 21:24:23 GMT
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 

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 

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}}}" % \

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 :-)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message