qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Some questions on 0.20 QMF Management Objects
Date Mon, 11 Feb 2013 15:42:44 GMT
Hi Fraser,

Missed this:

>I'm curious about the "query" method on the Broker object, what's the
>point of this?

Debug-ability.  Its intent is to provide debug information for a given broker object, not
to substitute for the information already available in the schema.

The QMF schema for a Queue object (or any other broker object) is the same for all types of
queues implemented in the broker.  As an abstraction, that Queue object only exports those
properties and statistics that are generic enough to meaningfully apply to all queue implementations.

However, it's useful to be able to gather information about the internal state of a queue's
implementation.  Otherwise, should a queue (or any other type of broker object) start to exhibit
a strange behavior in the field, we really have no visibility into the implementation-specific
state of the queue.  The schema can tell us very useful information about the queue, but not
all the dirty implementation-specific details.  Nor should it - we don't want to start overloading
the schema definition of a queue with various attributes that are specific to any one implementation.
 These things tend to change over time and vary among broker implementations.

The broker query method returns a map whose contents will be specific to a given queue implementation.
 These contents should give visibility into the internal state of the queue, and really don't
have any use beyond helping a developer debug a problem.

Having said that - yes, that method should be better documented as to its intended use.  I'll
fix that. 

-K

----- Original Message -----
> Hello All,
> I've been looking through the management-schema.xml for 0.20 and
> noticed
> a fair few new bits and bobs so I'd be interested in answers to the
> following question.
> 
> What's the intention behind the Memory Object? There seems to be
> quite a
> few properties described about low-level details of broker
> memory-management but I'm intrigued about why it has been exposed as
> a
> Management Object and how it's intended to be used.
> 
> There's been a lot of new additions to the Broker object which mostly
> look useful, but what's the intention of the get/set TimestampConfig?
> How would "timestamping received messages" be used?
> 
> I'm curious about the "query" method on the Broker object, what's the
> point of this? If I've interpreted the comments correctly it's
> suggesting that doing query with {"type": "queue", "name":
> "somequeue"}
> would return a result Map containing the map encoded QmfData for the
> queue named "somequeue".
> 
> If that's the case I'm really not at all clear what the point of it
> is,
> it seems rather redundant. Surely if one wants to get this
> information
> then doing a query for queue then finding they queue you want and
> doing
> subsequent queries using its ObjectId would serve exactly the same
> purpose?? To be fair with the query method you don't have to
> initially
> do a get for queues, but OTOH you do need to recover the broker
> Object
> to invoke the queue method on.
> 
> It may be that it's just about adding some choice, but is it so much
> more useful than the alternative? It seems that it may just be adding
> bloat and possibly confusion for limited benefit. Of course I may
> have
> missed something??
> 
> 
> 
> On the Queue object there's a new "filter" argument on "purge" and
> "reroute" (and on "queueMoveMessages" on Broker). Is there any
> documentation on how one would use the filter argument? It's clearly
> a
> Map, but I haven't noticed anything documented about how to populate
> the
> Map - am I going to have to consult the "one true source of
> documentation" AKA the source code :-) ????
> 
> Cheers,
> Frase
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

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


Mime
View raw message