qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Questions from a novice
Date Tue, 02 Apr 2013 13:26:52 GMT
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


Mime
View raw message