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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
