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 Tue, 02 Apr 2013 18:01:52 GMT
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?


On 2 Apr 2013, at 14:26, Ken Giusti <kgiusti@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.adams@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 <kgiusti@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
> -- 
> -K
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message