qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Freeman <ke1g...@gmail.com>
Subject Re: Questions from a novice
Date Mon, 01 Apr 2013 16:06:57 GMT

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 <kgiusti@redhat.com> 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

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