----- Original Message ----- > From: "Bill Freeman" <ke1g...@gmail.com> > To: users@qpid.apache.org > Sent: Friday, April 5, 2013 12:45:02 PM > Subject: Re: Questions from a novice > > Ken, > > Yes, with the patch in, I get callbacks to my qmf.console.Console sub-class > instance's callback methods for both V1 and V2 updates.
Great! I've submitted this fix to QPID. If it proves stable, I'll ask permission to get it in our next release candidate. > > There are some differences in the plumbing: > > V1 initial updates carry properties only. V2 initial updates carry > both properties and statistics. Both are sent to the objectProps() > callback. > > Subsequent updates carry only statistics, for both V1 and V2. However, > for V1 these updates are sent to the objectStats() callback, while for V2 > they are sent to the objectProps() callback. (I wonder if this was > intended, or whether these were intended to go to objectStats() in V2 as > well). I have to smile at this - when I was fixing the bug I was surprised at this behavior. I had to look into a bit but, yes, it actually is intended (though it certainly needs more documentation). A bit of a history lesson as to why it works this way: Pre-V2, we defined the Console callback interface. At that time (Qmfv1), object statistic updates and object property updates were sent in separate messages. This was done as an optimization - in V1 all update messages are statically defined: they contain all properties (for property update) or all statistics (for statistic updates). If we didn't split along property/statistics - we'd have to send the entire object every time there was a statistics update. So there were two types of update messages, and hence two types of callbacks. Now along comes V2, which allows for "sparse" object updates (you only have to send those properties/statistics that change - not all of them). So now we only send one object update message, which contains only those properties and stats that have changed. Much more efficient. But what to do about the existing API? We probably should've broken backward compatibility, and I don't know the details (or, more likely, have blocked them out) but instead we only call objectProps() for these updates. > > Hereafter "oid" is an instance of qmf.console.ObjectId acquired by calling > the getObjectId() method of the qmf.console.Object instance that is passed > to the callbacks. > > Yes, str(oid) is much prettier for V2. Having the final component be the > queue name clearly assures stability across broker restarts and unrelated > configurations. I had trouble with that belief for the hash that is the > final component of the same string for V1. > > But the first 4 (dash separated) components of str(oid) don't seem useful > for my purpose of a within broker unique and restart stable identifier. > (Those first four come from oid.getFlags(), oid.getSequence(), > oid.getBrokerBank(), and oid.getAgentBank(), and turn into single digit > numbers for my test case.) I think that oid.getObject() (returns > oid.objectName, using this directly might be clearer) is more than enough > (on a V2 ObjectId instance, anyway). Please let me know if you disagree. > Yes, you should be fine using oid.getObject(). The other stuff, flags, broker bank, etc, are probably irrelevant for your purposed. The Sequence number will increment on each restart of qpidd for non-durable objects (non-durable queues, exchanges, etc), but what that really means is up to your application. If you're planning on using the same object names across broker restarts to identify 'logically' same object, you can ignore sequence number changes. > oid.isV2 seems to be the correct place to check to know which sort of > record I have. For now, it I only want to process one kind of record (the > useful V1 and V2 information is redundant) I'm going to use this flag. Yes, that flag is used to distinguish between the two formats. > > However, it would be nice to know how to get the console to only subscribe > to the V2 queues. It's not clear that I can require the brokers to be > reconfigured as no v1, so it would be nice if there were a console option. > I'll do a bit more reading of the source code, but if anyone can shortcut > that, I'd appreciate it. > Hmmmm... you know, I don't think the console allows you to filter out v1. Personally, I'd like to see the default behavior of the broker changed to only send V2 updates, rather than both. People who need v1 would have the option of turning it on. Too late to ask for that for the next release, but I'll add a JIRA and try to get that into the following release. Or at least add an option to filter v1 at the console. > Bill > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
