From users-return-7714-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Mon Feb 11 15:43:19 2013 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1F5C3EB90 for ; Mon, 11 Feb 2013 15:43:19 +0000 (UTC) Received: (qmail 7025 invoked by uid 500); 11 Feb 2013 15:43:19 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 6533 invoked by uid 500); 11 Feb 2013 15:43:13 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 6349 invoked by uid 99); 11 Feb 2013 15:43:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2013 15:43:12 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kgiusti@redhat.com designates 209.132.183.24 as permitted sender) Received: from [209.132.183.24] (HELO mx3-phx2.redhat.com) (209.132.183.24) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2013 15:43:05 +0000 Received: from zmail16.collab.prod.int.phx2.redhat.com (zmail16.collab.prod.int.phx2.redhat.com [10.5.83.18]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1BFgiZZ021223 for ; Mon, 11 Feb 2013 10:42:44 -0500 Date: Mon, 11 Feb 2013 10:42:44 -0500 (EST) From: Ken Giusti To: users@qpid.apache.org Message-ID: <141206471.330339.1360597364556.JavaMail.root@redhat.com> In-Reply-To: <5117D634.9000001@blueyonder.co.uk> Subject: Re: Some questions on 0.20 QMF Management Objects MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.16.187.66] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - FF3.0 (Linux)/7.2.0_GA_2669) X-Virus-Checked: Checked by ClamAV on apache.org 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