Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of kgiusti@redhat.com designates
 209.132.183.25 as permitted sender)
Date: Tue, 2 Apr 2013 17:22:40 -0400 (EDT)
From: Ken Giusti <kgiusti@redhat.com>
To: users@qpid.apache.org
Message-ID: <392911768.879183.1364937760035.JavaMail.root@redhat.com>
In-Reply-To: <3D826D6B-C2BC-43E3-82CE-A97C47E24FB1@blueyonder.co.uk>
References: 
 <CAB+Aj0t4z6mRXZii=bV8bwBoS5FAfbsgmJR6GZJM8zkTFDHaVg@mail.gmail.com>
 <CAB+Aj0uy_KrcwAE+AzOC4SfyGTY2Sec5tgkrgWzE2ocyyxf4hw@mail.gmail.com>
 <5159B3F1.3030804@redhat.com>
 <CAB+Aj0snDjRhV_m+JQWN4nVYjvd=1zR0LSwb=F0PfgZ66mE-cw@mail.gmail.com>
 <240816474.280610.1364848314232.JavaMail.root@redhat.com>
 <9E48CFDF-DBA7-4193-A39A-FFCED58EC104@blueyonder.co.uk>
 <1922558928.614074.1364909212961.JavaMail.root@redhat.com>
 <3D826D6B-C2BC-43E3-82CE-A97C47E24FB1@blueyonder.co.uk>
Subject: Re: Questions from a novice
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Questions from a novice
Thread-Index: CgqrNbOVhbzpm9rowicYFWNrflZUsw==

When console.py connects to a broker (via addBroker), it will attempt to query for the existence of the qmf.default.direct and qmf.default.topic exchanges.  If that query succeeds, the console marks that broker as being V2 capable, and uses V2.  Otherwise it falls back to V1.

Take a look at the Broker::_tryToConnect() method in console.py for all the gory details.

-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 2:01:52 PM
> Subject: Re: Questions from a novice
> 
> 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 <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
> 
> 

-- 
-K

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