Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 81.103.221.49 as permitted sender)
Message-ID: <515C4DEA.4030809@blueyonder.co.uk>
Date: Wed, 03 Apr 2013 16:42:34 +0100
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Questions from a novice
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>
 <392911768.879183.1364937760035.JavaMail.root@redhat.com>
 <CAB+Aj0uBf347UkmTkeKwjyn1RH5+MoQnK7Uk3Ldy0pnAJC1J0Q@mail.gmail.com>
In-Reply-To: 
 <CAB+Aj0uBf347UkmTkeKwjyn1RH5+MoQnK7Uk3Ldy0pnAJC1J0Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/04/13 14:45, Bill Freeman wrote:
>
> And, in fact, my broker has those exchanges,
For info I think that every qpid version from at least 0.8 has supported 
QMF2 ()in the C++ broker) so these exchanges are almost certain to be 
present unless you have really old brokers around (and if you do I'd 
recommend you suggest to whoever owns them to upgrade)

>   and console.py finds them and
> sets the Broker instance's brokerSupportsV2 attribute to True.  And the
> brokerAgent it gets has isV2 True.  And it creates its v2 queues,
> binds/subscribes them, etc.
>
> So I'm guessing that the rcvOjbects flag to the Session constructor only
> gets me V1 updates, and I would have to subscribe explicitly to the queues
> that I care about in order to get v2 updates.  Does that sound right?
My guess is that if the initial Broker object set up has successfully 
queried for the presence of QMF2 exchanges then you'd get V2 updates. 
Actually I've looked at "class Session:" and the following code in 
_bindingKeys suggests to me that for the case of asynchronous receipt of 
broker data pushes the class is setting up subscriptions to both QMF1 
and QMF2 topics

   def _bindingKeys(self):
     v1KeyList = []
     v2KeyList = []
     v1KeyList.append("schema.#")
     # note well: any binding that starts with 'agent.ind.heartbeat' will be
     # bound to the heartbeat queue, otherwise it will be bound to the
     # unsolicited indication queue.  See _decOutstanding() for the binding.
     if not self.userBindings:
       if self.rcvObjects and self.rcvEvents and self.rcvHeartbeats:
         v1KeyList.append("console.#")
         v2KeyList.append("agent.ind.data.#")
         v2KeyList.append("agent.ind.event.#")
         v2KeyList.append("agent.ind.heartbeat.#")
       else:
         # need heartbeats for V2 newAgent()/delAgent()
         v2KeyList.append("agent.ind.heartbeat.#")
         if self.rcvObjects:
           v1KeyList.append("console.obj.#")
           v2KeyList.append("agent.ind.data.#")
         else:
v1KeyList.append("console.obj.*.*.org.apache.qpid.broker.agent")
         if self.rcvEvents:
           v1KeyList.append("console.event.#")
           v2KeyList.append("agent.ind.event.#")
         else:
v1KeyList.append("console.event.*.*.org.apache.qpid.broker.agent")
         if self.rcvHeartbeats:
           v1KeyList.append("console.heartbeat.#")
     else:
       # mandatory bindings
v1KeyList.append("console.obj.*.*.org.apache.qpid.broker.agent")
v1KeyList.append("console.event.*.*.org.apache.qpid.broker.agent")
       v1KeyList.append("console.heartbeat.#")  # no way to turn this on 
later
       v2KeyList.append("agent.ind.heartbeat.org_apache.qpidd.#")

     return (v1KeyList, v2KeyList)

and later in bindClass() I see:

     for broker in self.brokers:
       if broker.isConnected():
         broker.amqpSession.exchange_bind(exchange="qpid.management", 
queue=broker.topicName, binding_key=v1key)
         if broker.brokerSupportsV2:
           # data indications should arrive on the unsolicited 
indication queue
broker.amqpSession.exchange_bind(exchange="qmf.default.topic", 
queue=broker.v2_topic_queue_ui, binding_key=v2key)

Which looks like it first binds from the QMF1 qpid.management topic 
exchange to some queue with the v1key then if brokerSupportsV2 is set 
binds from the QMF2 qmf.default.topic exchange to some other queue with 
the v2key


I couldn't say for sure without looking at the code in more detail but 
my guess is that data is being pushed from the broker in both QMF1 and 
QMF2 format and is probably being placed on both of the queues above, in 
your case the data is being read off the QMF2 queue and I'd bet that the 
QMF1 queue just fills up and circulates (it's a ring queue) you could 
probably check this by monitoring the depth of the queue whose name 
starts "topic-", the QMF2 topic queue starts "qmfc-v2-ui-".

I'm no expert on this code, so it's just a guess on my part, I'm kind of 
curious myself now :-)

Frase


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