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.
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].
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.
-K
----- Original Message -----
> From: "Gordon Sim" <g...@redhat.com>
> To: users@qpid.apache.org
> Sent: Monday, April 1, 2013 10:32:43 AM
> Subject: Re: Questions from a novice
>
> On 04/01/2013 02:12 PM, Bill Freeman wrote:
> > On Mon, Apr 1, 2013 at 8:24 AM, Bill Freeman <ke1g...@gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On Mon, Apr 1, 2013 at 5:03 AM, Gordon Sim <g...@redhat.com> wrote:
> >>
> >>> On 03/29/2013 04:35 PM, Bill Freeman wrote:That console API is a bit of a
> >>> mixture of QMFv1 and QMFv2. I think there is a getObjectId() method, and
> >>> you can then call asMap() on that to get the v2 form.
> >>>
> >>
> >> Thanks. I'll have a read of the method code, call it with pdb, to see
> >> what it does for me.
> >>
> >
> > OK. That gives me:
> >
> > 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.
>
> I suspect it is merely that your use of the console API is following a
> v1 path. Unless you are using a very old broker, it will speak both v2
> and v1. I'm not sufficiently knowledgeable about that API to help but
> will try and get hold of someone who is...
>
> There is a much simpler, more basic library available for v2 available
> as well:
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/py/qpidtoollibs/broker.py.
> Depending on your needs and your existing ties to the console API that
> may be worth a look.
>
> > I'm forced to re-ask whether, in the V1 context:
> > 1. Are the name properties of queues still enforced to be unique within
> > a
> > broker?
> > 2. Are those _object_name values, '18449' still guaranteed to be stable
> > across, for example, deleting a pair of queues, restarting qpidd, and
> > re-creating the queues in the other order from which they were first
> > created?
> > 3. Is that '18449' some kind of hash or what?
> >
> > Thanks, Bill
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
