On 9 March 2014 12:02, Fraser Adams <fraser.ad...@blueyonder.co.uk> wrote:
> 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: @0...@org.apache.qpid.broker:queue:TempQueue75f56193-3ff6-
> 445e-8f43-8ddef83e25ef
> childAdded: BindingImpl.agent.ind.#
> setExchangeRef: @0...@org.apache.qpid.broker: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: @0...@org.apache.qpid.broker:queue:TempQueuedffb629b-f2a0-
> 4d8e-9ad2-adb8c7f38b0d
> childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6.async
> setExchangeRef: @0...@org.apache.qpid.broker: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: @0...@org.apache.qpid.broker:queue:TempQueue1306a57b-71b3-
> 478d-8c51-27449b8e2e7e
> childAdded: BindingImpl.admin.4cbb68e6-a7fe-4b56-82ab-a15ccb7741d6
> setExchangeRef: @0...@org.apache.qpid.broker: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 :-)
>
I will have to make do with this large coffee in Amsterdam Schiphol
instead, not sure how the residents of Edinburgh would take to me arriving
both tired *and* a little tipsy and then trying to drive on the other side
of the road than I'm now used to :-)
Glad to hear it's a little healthier now, though I couldn't really explain
what you were seeing before... the worst I think you should have been
seeing is spurious creates if a binding was being created but then it was
discovered an existing binding already matched... oh well... let me know if
there are any other issues.
-- Rob
>
> Cheers,
> Frase
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
