Hi Fraser, >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?
That feature provides for the timestamp as described in AMQP 0.10 message.delivery-properties. It's an optional property of the message, and turning it on does impact performance. Hence it needs to be configurable, and having it be configurable "on demand" - and thus presented as a broker method - is more useful than having to stop/reconfigure/start a live broker. Especially if you need to debug a broker "in the field". I added it to help in debugging broker behavior wrt message groups where a group may not get claimed for a period of time. The timestamp can be used to gauge how long the message has been sitting in the broker unclaimed. Too long, and there's probably a problem with how clients are consuming groups. More info on message groups: http://qpid.apache.org/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/Using-message-groups.html >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 provides the capability to "cherry-pick" which messages to purge/reroute based on the contents of the message's headers. This is specifically useful for message groups - it gives you the ability to purge/reroute a particular message group (for example, should consumers for that queue no longer accept messages from a particular group). There are examples of this use in tests/src/py/qpid_tests/broker_0_10/msg_groups.py. The current implementation only allows for an exact match against message headers. Since the filter is a map, we're relatively free to add other filter types (e.g. delete those messages > 1meg in size, etc). -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]
