Ken, Please forgive me if I say "browser" anywhere in here. I mean "broker" but "browser" seems to fall out of my fingers in the heat of typing.
On Mon, Apr 1, 2013 at 11:36 AM, Ken Giusti <[email protected]> wrote: > Hi Bill (and Gordon) - sorry about not chiming in a bit earlier with this. > > Bill - though you've probably already seen it, the management schema is > the definitive source for the format of all management objects made > available via QMF: qpid/specs/management-schema.xml. It also defines the > keys (index) used by the object ids. > Actually, I hadn't seen that, though I presume that the schema the console fetches for various object types is similar. > As Gordon correctly mentioned, there are two versions of QMF supported by > the brokers. The original version - often referred to as QMFv1 - uses a > very terse binary representation of those management object defined in that > schema XML file. The v1 object id is also a weird hash-based numeric > identifier. QMFv2 improves on this by using AMQP maps to represent these > objects (and other components, like the object ids). Maps are a big > improvement, as they are easier to manipulate in most languages (like > python), and are "self identifying" - you can make sense of them without > the need for parsing out the schema, decoding binary, etc. > > Having said that - you should definitely be using the v2 variant. Brokers > currently speak both (you can control this via the command line switches to > the qpidd broker daemon, if you want to disable v1 support and only speak > v2, for instance). But the application can use either. Most of the tools > speak V2, and use the qpidtoollibs library to do that. > > Now for object ids - the v2 object id is a map that contains a few fields, > one of which is the _object_name. The _object_name is a string that > uniquely identifies the object. It is composed of the package, class, and > object's identifying keys. The keys are those properties from the object's > schema definition that are marked as index's. For example, the Queue class > from the management-schema.xml file: > > > <class name="Queue"> > <property name="vhostRef" type="objId" references="Vhost" > access="RC" index="y" parentRef="y"/> > <property name="name" type="sstr" access="RC" index="y"/> > > <property name="durable" type="bool" access="RC"/> > <property name="autoDelete" type="bool" access="RC"/> > <property name="exclusive" type="bool" access="RO"/> > > [snip] > > The Queue's object Id will be a map composed of the vhostRef (which is an > object Id itself) and the queue's name. These properties have the 'index=y' > attribute set. [I'm unsure if vhostRef is actually used. The queue name > definitely is]. > I'm looking to uniquely identify objects across a federation (or possibly even unrelated brokers), across restarts and (minor) reconfigurations. Thus I believe I have to identify the broker, and combine that, with, say, V2 object name. Earlier in the discussions I got the impression that there wasn't necessarily unique across brokers, or at least no better than host IP address and broker port number(*). Unless something as good or better in a vhostRef, I'm probably still compositing IP, port, and V2 object name. Any thoughts? [* I'll ignore the possibility of identical unroutable IP addresses on separate NATed sub-nets, or machines answering to more than one IP address.] > Now, for this case: > > > > > p qmfID.asMap() > > > {'_object_name': '18449', '_agent_name': '0'} > > > > > > So these still don't seem very name like to me. I was interpreting the > > > name of the queue as being the value of the name property. I see that > this > > > is arriving via Agent._handleQmfV1Message(), so I guess my broker(s) > speak > > > V1. > > You're correct - this is a map representation of a V1 style object id. > Not very pretty. If you were talking V2, that _object_name field should > be a string composed of the concatenation of the package, class, and index > fields [ie. queue's name] from the class definition as per the schema. > > You probably want to use the qpidtoollibs as Gordon suggested. It speaks > v2, and it's used by (most) of the command line tools for accessing the QMF > objects. See the qpid/tools/src/py directory in the repo. You can use > qpid-config as an example. > > Can I still work in an asynchronous mode with these tools? And separately, since I have a dog and pony show coming up shortly, do you know how to get the existing qmf.console stuff to send my updates as V2 (session has rcvObjects True). Thanks, Bill
