qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: The new QMF2 qpid-config appears to have some "quirks"
Date Tue, 05 Mar 2013 17:04:06 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message