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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
