On 09/03/14 10:24, Rob Godfrey wrote:
Sorry for all the small posts... not sure when boarding is going to be
called... so sending things as soon as they are almost coherent :-)
You are a crazy man Mr Godfrey :-)
Ok... I'll take a quick look now and at the various airports at which I'm
going to be at during the day....
very crazy indeed!!
Do you mean getBindings() is returning an empty set?
I'm not seeing a way that getBindings() could return anything other than
the current set of bindings...
I was taking a look through the AbstractExchange code and I was about to
post that it looks like childAdded only gets called on createBinding
which looked like it was the problem then I noticed you'd committed some
changes. I've rebuilt and it's looking like it's working now, though
I'll need to check more closely. I see AbstractExchange now has a
makeBinding method that takes care of the housekeeping.
With my debug enabled I'm seeing the following when I add a QMF
Connection - which looks a lot healthier:
childAdded: ConnectionAdapter.192.168.1.108:45591
childAdded: SessionAdapter.0
childAdded: SessionAdapter.1
childAdded: StandardQueue.TempQueue75f56193-3ff6-445e-8f43-8ddef83e25ef
childAdded: BindingImpl.agent.ind.#
setQueueRef:
@[email protected]:queue:TempQueue75f56193-3ff6-445e-8f43-8ddef83e25ef
childAdded: BindingImpl.agent.ind.#
setExchangeRef: @[email protected]:exchange:qmf.default.topic
childAdded: QueueConsumerImpl.1
childAdded: QueueConsumerImpl.1
childAdded: StandardQueue.TempQueuedffb629b-f2a0-4d8e-9ad2-adb8c7f38b0d
childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6.async
setQueueRef:
@[email protected]:queue:TempQueuedffb629b-f2a0-4d8e-9ad2-adb8c7f38b0d
childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6.async
setExchangeRef: @[email protected]:exchange:qmf.default.direct
childAdded: QueueConsumerImpl.2
childAdded: QueueConsumerImpl.2
childAdded: StandardQueue.TempQueue1306a57b-71b3-478d-8c51-27449b8e2e7e
childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6
setQueueRef:
@[email protected]:queue:TempQueue1306a57b-71b3-478d-8c51-27449b8e2e7e
childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6
setExchangeRef: @[email protected]:exchange:qmf.default.direct
childAdded: QueueConsumerImpl.1
childAdded: QueueConsumerImpl.1
some more comments at the bottom of the mail......
2) Looking at bindings navigating from a queue it *looks* like the
binding shown is the queue binding not the exchange binding (I'd expect to
see a binding to an exchange when looking from a queue if you see what I
mean)
There is only one "binding" which has parents being both the queue and the
exchange, so you get getParent(Queue.class) to get the Queue parent and
getParent(Exchange.class) to get the Exchange parent....
getQueue() and getExchange() and getAttribute("queue") and
getAttribute("exchange") will also work... and there is no way that those
methods can bring back an object of the wrong type...
@Override
public Queue getQueue()
{
return _queue;
}
@Override
public ExchangeImpl getExchange()
{
return _exchange;
}
and from getAttribute(String name)...
else if(QUEUE.equals(name))
{
return _queue;
}
else if(EXCHANGE.equals(name))
{
return _exchange;
}
In QMF terms it's suggesting that the exchangeRef is actually pointing to
a Queue and that the queueRef is missing (I think) but in terms of the Java
Broker stuff it's the Queues and Exchanges that are parents of Bindings so
I'm not quite sure what's happening - I think either an Exchange or Queue
is not calling childAdded (which would account for not seeing bindings
navigating from an exchange) but it's weird that the other childAdded is
having the wrong parent being passed (which I think is the only way to
account for me seeing the wrong bindings).
So I think you'll get notifications for both the Exchange and the Queue
having the child added...
In terms of the core broker code, both the queue and the exchange object
will call
childAdded(binding)
This will result in all the listeners being called with childAdded(this,
binding) ... so there is no way the queue can generate a notification for
the exchange or vice versa. As above though you should get two
notifications for every binding (one for the queue and one for the
exchange).
-- Rob
So your makeBinding change looks like it has done the trick, the other
weirdness that I was seeing is likely to be accounted for by there being
garbage in my "exchangeRef" - so your fix results in my setExchangeRef
stuff getting called on my org.apache.qpid.server.qmf2.agentdata.Binding
instance which sets the exchangeRef property on the QMF object.
Thanks for looking at this - I wasn't expecting a result this quickly.
There can't be too many people sat in airports on Sunday morning
actually doing *code* on their laptops - kudos!!
It's now past 11:00 have a beer instead :-)
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
