----- Original Message ----- > From: "Bill Freeman" <[email protected]> > To: [email protected] > Sent: Friday, April 5, 2013 2:37:23 PM > Subject: Re: Questions from a novice > > On Fri, Apr 5, 2013 at 2:09 PM, Ken Giusti <[email protected]> wrote: > > > > > > > ----- Original Message ----- > > > From: "Bill Freeman" <[email protected]> > > ... > > > > > > 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. > > > > If it has already arrived in the console process, then the bandwidth has > already been used, and it makes little difference whether I filter it or > the underlying console code does. I'd been thinking that, if at the time > the session is set up, the console did not subscribe to the V1 queues (or > should I say bind to the V1 exchanges?), then V1 updates wouldn't get sent > over the wire. (In fact, I have half a memory somewhere that if nobody > subscribes to the queues, the broker saves its own resources and time by > not issuing the updates.) >
Yes, absolutely true and very astute - simply dropping the update at the console would be wasteful. My own very bad choice of words - the actual 'filter' would need to work exactly as you describe: when set, prevent the console from binding to the V1 exchanges. Using such a option would not be without some risk to those deployments that have old V1 agents attached to the broker: you'd no longer get V1 updates from the broker, but you'd also lose access to all V1 agents attached to that broker. > > > > > 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. > > > > There is the hazard that someone using some V1 tools will have a hard time > deciding why, after an upgrade, things have stopped working. After all, > the broker still supports V1 (if their knowledge is that deep). I'm only a > contractor where I'm doing this, and I might easily have finished the > project with V1. It's not clear who will understand deeply enough after > I've moved on. > > Bill > Very true, but at some point I imagine that V1 will be deprecated. There is a cost, both in person-power and code complexity, to maintaining two parallel management implementations. Heck, I just spent two days fixing a bug that seems to be related to a V1 convention that broke the V2 path. And since the tests speak both variants, we didn't hit the bug as the functioning V1 code "hid" the V2 problem. QMF V2 has been available for some time now, and we've cut all the project tools and libraries over to speaking it. If we start down the road to deprecating V1, turning off the broker updates is about the least risky first step I can think of. It would not remove v1 at all - but it would require manual intervention to restore the old behavior. Having to explicitly take that action would be a (hopefully gentle) nudge to assess a deployment's V1 dependency. Of course, this is just my $0.02, certainly not a consensus by any means :) -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
