On 05/04/13 19:27, Ken Giusti wrote:
Your code is fine, and your observations are 100% correct. You
_should_ be seeing both, but are just getting V1 updates. That's the
bug from QPID-4689. I _just_ pushed a fix to trunk, so if you update,
you should start seeing V2 objects. The commit is here:
http://svn.apache.org/viewvc?view=revision&revision=1465050
Thanks Ken - I was questioning my sanity :-) TBH I noticed from earlier
in this thread that you had a patch in play but there's been a lot going
on in this thread and I had assumed that the patch was related to the
issue where if you did "--mgmt-qmf1 no" you didn't get any updates I was
using the broker defaults so I kind of "parked it" not realising that
there was more to it :-)
Yes, getting both is awkward at best. The root of the problem is that, by
default, brokers send two updates for each event - one in V1 format and one in
V2. The reason is to allow for backward and forward compatibility among
clients built for v1 and v2 serviced by the same broker.
Don't the V1 and V2 updates get published to different topics? I thought
that qmf.default.topic was for V2 and qpid.management was for V1 so
*surely" it ought to be possible to select.
Thinking about it given the bug QPID-4689 seems to suggest that V2
updates have never actually been delivered hitherto I'm thinking to
myself that perhaps defaulting to V1, but with a new flag/switch
whatever to select V2 in the API is the best approach.
I'd strongly suspect that applying your QPID-4689 fix and thus causing
callbacks from both V1 and V2 is *very* likely to break existing code. I
know that an "isV2" property on the ObjectIds has been mentioned, but
how likely do you think it is that clients are likely to test for this,
especially given that V2 updates are not likely to have actually occurred.
I think that we should do two things to address this:
1) start deprecating V1 in the broker by simply changing the default behavior
to only send updates as qmf V2. V1 format updates can be turned on manually if
needed.
2) fix the console by adding a configuration option to the Console to ignore V1
format object updates. The default would have to allow both, as some clients
may actually want both if some of their agents only speak v1.
I'd like to propose we do #1 after the next release (for 0.24). What do you
think?
Hmm much as I might like to deprecate V1 (and I know I only ever really
use V2 in anger from Java) but my guess is that there's a fair number of
python based QMF tools out there and given that it looks likely that V2
updates have never arrived prior to your fix I really think that your
proposed approach is in danger of breaking an unknown but non-trivial
number of tools. I know that the tool I've been messing with to try this
is a connection-audit tool which checks subscriptions queues against a
whitelist and alerts if someone tries to create a queue not in the
whitelist - it's a bit dear to my heart that one :-)
As I said earlier my preference would be for the API to default to V1
and receive only V1 updates and thus essentially behave as it does at
present prior to QPID-4689.
I think adding a switch to select V2 (I guess to the Session constructor
assuming that varargs are supported so not specifying doesn't break
existing clients) would be the right way IMHO.
I'm kind of happy with "start deprecating V1 in the broker by simply
changing the default behavior to only send updates as qmf V2" but given
that V2 updates to this API appear never actually to have hitherto
happened (if my understanding of QPID-4689 is correct) I think that some
more notice is needed - as I say I think that as proposed existing
clients are likely to break in I suspect subtle ways.
RE "fix the console by adding a configuration option to the Console to
ignore V1 format object updates. The default would have to allow both,
as some clients may actually want both if some of their agents only
speak v1. " As I say I think that the default really should be V1 only
because that's been the situation up until your fix.
One possibility may be to detect the V2 exchanges as is currently done
and automatically only select V2 updates but map them to the
objectProps/objectStats - as said previously at the moment V1 and V2
updates behave differently so making things only do objectProps as seems
to be the case for V2 will break things just about as much as sending
both V1 and V2 updates.
Personally I think it's cleaner to go with my earlier suggestion of
explicitly selecting V2. Frankly when it comes to publicising the
changes that might be necessary when finally deprecating V1 it might be
a whole lot easier to explain to people by pointing to some specific API
changes that they might need to invoke. I have to say that I've never
liked that API at the best of times and the slightly awkward mish-mash
of V1 and V2 I think is an accident waiting to happen.
It's going to be even more exciting when we start to migrate from QMF to
AMQP 1.0 management when that arrives. I think ultimately that's going
to be a good thing, but the transition path is going to be exciting :-)
especially if - like me - you'll have to cater for managing a "mixed
economy" of older and newer brokers.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
