qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Questions from a novice
Date Fri, 05 Apr 2013 19:18:49 GMT
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message