qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Questions from a novice
Date Mon, 01 Apr 2013 15:36:32 GMT
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" <gsim@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.nh@gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On Mon, Apr 1, 2013 at 5:03 AM, Gordon Sim <gsim@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message