Hi Frase, What I saw surprised me: when I disabled v1 (via --mgmt-qmf1 no) and I ran qpid-tool, qpid-tool didn't get any updates (no objects listed).
As you point out, the broker should be sending unsolicited object update notifications periodically. By default, each update message is sent in both v1 and v2 format (from what I remember). So by turning off v1, I still expected the broker to send the v2 updates. >From what I could tell, the broker _was_ sending v2 updates - dumping exchange >statistics (qpid-stat -e) showed activity on the qmf.default.topic. So why >wasn't qpid-tool showing the objects (it uses the Console callback method >AFAIK). Turns out there's a bug in the object update handling code in console.py. See the patch in https://issues.apache.org/jira/browse/QPID-4689 >From what I can tell, the console.py expects the management agent of the local >broker to identify itself as "broker" via the "qmf.agent" header in the >message. This assumption appears to have broken: I've observed the current >behavior as the broker is now sending it's fully qualified agent name in the >"qmf.agent" field instead (this would be in the form ><vendor>:<product>:<instance> - in the case of the broker it would be >"apache.org:qpidd:<xxx>" where <xxx> defaults to the mgmt uuid. I'm not sure when this broke, or why. But I think the "broker" convention is a left over from qmfv1 support. With V2 the broker's agent name should be that fully qualified triplet from above. The patch changes the code to recognize either format. Seems to work - qpid-tool now reports all the objects if the broker is started with --mgmt-qmf1 no. I suspect if we ever do away with v1 support, we could probably simplify the console.py code quite a bit. I find it's current form a bit squirrelly and loaded with special cases in order to support both qmf versions. -K ----- Original Message ----- > From: "Fraser Adams" <fraser.ad...@blueyonder.co.uk> > To: users@qpid.apache.org > Cc: users@qpid.apache.org > Sent: Tuesday, April 2, 2013 3:52:44 AM > Subject: Re: Questions from a novice > > > > On 1 Apr 2013, at 21:31, Ken Giusti <kgiu...@redhat.com> wrote: > > > Hi Bill, > > > > I've just tried to restrict my broker to using only qmf v2: > > > > $ qpidd --auth no --mgmt-qmf1 no > > > > and I no longer get update notifications from my console.py app! From the > > looks of it, the console.py code is broken - the broker is generating the > > qmfv2 updates, but console.py is dropping them. This is on trunk - I'll > > open a JIRA. > > > Ken, surely what you are observing is the correct behaviour? With QMF1 there > were two python APIs one (the most commonly used one) was synchronous and > mainly used the getObjects() calls to query for objects of a given type e.g. > queue, exchange, bind etc. the other API, used by I think qpid-queue-stat > and I think being referred to in this thread is asynchronous. The > asynchronous API relies on the broker data push and a subscription on a > given topic so if you do --mgmt-qmf1 no then the broker data push to that > topic, which pushes things like heartbeats and statistics updates, won't > occur. > > Unless of course you are actually saying that disabling QMF1 data push > actually stops the QMF2 data push??? I've not checked for that - it wouldn't > totally surprise me as the two blocks of code in the broker are fairly > intertwined and it's more likely that people would use the default behaviour > with both QMF1 and QMF2 enabled. > > Hmm re-reading your post you do seem to be talking about perhaps something > different? I am perhaps jumping to conclusions based on Bill's comments that > he's using QMF1? > > Frase > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
