Hi Ken, I hadn't realised that the asynchronous python API actually had QMF2 support at all, I has assumed that both the original APIs were QMF1 only. I'm definitely learning something - though I'm not especially fond of that particular API, I find it a bit fiddly.
It has been a long while since I did anything with that API - how do you get the API to choose between QMF1 or QMF2? I know at the protocol level for QMF2 it's a subscription to qmf.default.topic/agent.ind.* or something similar but I don't recall noticing how to select one protocol or the other via that API? Frase On 2 Apr 2013, at 14:26, Ken Giusti <kgiu...@redhat.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
