Ok... I'll take a quick look now and at the various airports at which I'm
going to be at during the day....

-- Rob
On 9 Mar 2014 10:22, "Fraser Adams" <fraser.ad...@blueyonder.co.uk> wrote:

> I took another look at this - there's definitely still a few problems with
> the bindings. I think that the disparity between the bindingCount attribute
> and the reported bindings is almost certainly due to the removal of
> default.direct not being fully reflected everywhere, however there are
> other issues:
> 1) Looking at bindings navigating from an exchange I'm not seeing any
> bindings
> 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)
>
> 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 in other words superficially this *looks* better, but it's currently
> reporting the wrong information.
>
> Frase
>
>
> On 08/03/14 20:24, Fraser Adams wrote:
>
>> Hey Rob,
>> It's looking a lot better, but I don't think it's quite there yet - I
>> seem to be seeing a mismatch between the bindingCount property of queues
>> and the actual bindings I'm seeing and I don't seem to be seeing bindings
>> at all when I navigate from the qmf.default.direct and qmf.default.topic
>> exchanges.
>>
>> The former might well be to do with the removal/hiding of the no-name
>> default.direct exchange that was done recently in the Java Broker the
>> latter points to a potential child issue remaining.
>>
>> I'll investigate a bit more tomorrow and post an update when I've figured
>> out what's occurin'
>>
>> Cheers,
>> Frase
>>
>>
>> On 08/03/14 19:00, Rob Godfrey wrote:
>>
>>> OK... I've made some changes which will hopefully correctly call the
>>> child
>>> added / removed at appropriate times for consumer/binding and session
>>> creation...
>>>
>>> Let me know if you are still seeing issues (though I'm not going to be
>>> around much for the rest of the weekend... travelling tmr)
>>>
>>> -- Rob
>>>
>>>
>>> On 8 March 2014 18:34, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> On 8 March 2014 18:09, Fraser Adams <fraser.ad...@blueyonder.co.uk>
>>>> wrote:
>>>>
>>>>  On 08/03/14 16:16, Rob Godfrey wrote:
>>>>>
>>>>>  So... looking at it now... I think bits of it were broken before (the
>>>>>> sessions on connections thing is horribly broken and always has been),
>>>>>> but
>>>>>> it was broken a little bit more by some of the refactoring changes.
>>>>>>
>>>>>>  I certainly *used* to get enough info to be able to track Bindings
>>>>> and
>>>>> Subscriptions and to be able to navigate between Connection->Session->
>>>>> Subscription->Queue
>>>>> and vice versa and
>>>>> Exchange->Binding->Queue and vice versa
>>>>>
>>>>>
>>>>>  The Sessions only seem to be populated (and then the childAdded kicked
>>>> off) the first time you do getSessions() on a connection... and then it
>>>> never notices new sessions being added (again until you do a
>>>> getSessions())
>>>>
>>>>
>>>>  But it definitely seems pretty broken at the moment. Man that
>>>>> refactoring
>>>>> had me swearing a lot :-(
>>>>>
>>>>>
>>>>>  :-) It will all work better in the end, honestly... If your code was
>>>> integrated into the build a bit better I would have made the changes as
>>>> I
>>>> went through (might not have spotted the breaking of the child added
>>>> stuff
>>>> though)... once Andrew/Robbie have got it (and the rest of the build)
>>>> mavenized, then InetlliJ will be able to cope a lot better with it I
>>>> think.
>>>>
>>>>
>>>>
>>>>>  I'll try to apply something today that will not only unbreak the
>>>>>> stuff I
>>>>>> broke, but get the sessions stuff and everything else working too... I
>>>>>> may
>>>>>> be a few hours :-)
>>>>>>
>>>>>>  That'd be great - think of it as pennance! ;-p
>>>>>
>>>>>
>>>>>  :-) Yeah... time for me to get back to beating myself with a stick...
>>>>
>>>> -- Rob
>>>>
>>>>
>>>>
>>>>>  -- Rob
>>>>>>
>>>>>> On 8 March 2014 15:19, Fraser Adams <fraser.ad...@blueyonder.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>   In case it helps:
>>>>>>
>>>>>>> I've enabled some debug code to my
>>>>>>> public void childAdded(final ConfiguredObject object, final
>>>>>>> ConfiguredObject child)
>>>>>>>
>>>>>>> and when I connect from a QMF Console I see
>>>>>>>
>>>>>>>
>>>>>>> childAdded: ConnectionAdapter.192.168.1.108:51674
>>>>>>> childAdded: StandardQueue.TempQueue6be15a5e-e2e8-455d-
>>>>>>> 91fe-f9c4d0065163
>>>>>>> childAdded: StandardQueue.TempQueuee06bd915-ed51-4072-
>>>>>>> 9565-0f4b8f879dbc
>>>>>>> childAdded: StandardQueue.TempQueuecb017ab2-66e2-41d4-
>>>>>>> a700-b488d7963055
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm slightly concerned that I'm not seeing SessionAdapter - there's
>>>>>>> definitely "childAdded(adapter)" in ConnectionAdapter.getSessions()
>>>>>>> so
>>>>>>> it's probably due to the "if(!_sessionAdapters.
>>>>>>> containsKey(session))"
>>>>>>>
>>>>>>>
>>>>>>> Actually - I've just seen something weird. When I *kill* the QMF
>>>>>>> Console I
>>>>>>> see:
>>>>>>>
>>>>>>> childAdded: SessionAdapter.0
>>>>>>> childAdded: SessionAdapter.1
>>>>>>>
>>>>>>> ????????
>>>>>>>
>>>>>>>
>>>>>>> That seems to be happening consistently.
>>>>>>>
>>>>>>> If I add chidRemoved debug too I see:
>>>>>>>
>>>>>>> <when I add a QMF Console>
>>>>>>> childAdded: ConnectionAdapter.192.168.1.108:56590
>>>>>>> childAdded: StandardQueue.TempQueue2aedf125-368a-4c5b-
>>>>>>> ab01-297d5c9c19bb
>>>>>>> childAdded: StandardQueue.TempQueuef5b4e0f2-aea6-4cb6-
>>>>>>> 9e94-697c91076457
>>>>>>> childAdded: StandardQueue.TempQueue8a4d6f9c-c28d-49dc-
>>>>>>> baa6-51da38252e7d
>>>>>>>
>>>>>>> <when I remove a QMF Console>
>>>>>>> childRemoved: StandardQueue.TempQueue8a4d6f9c-c28d-49dc-
>>>>>>> baa6-51da38252e7d
>>>>>>> childRemoved: StandardQueue.TempQueue2aedf125-368a-4c5b-
>>>>>>> ab01-297d5c9c19bb
>>>>>>> childRemoved: StandardQueue.TempQueuef5b4e0f2-aea6-4cb6-
>>>>>>> 9e94-697c91076457
>>>>>>> childAdded: SessionAdapter.0
>>>>>>> childAdded: SessionAdapter.1
>>>>>>> childRemoved: ConnectionAdapter.192.168.1.108:56590
>>>>>>>
>>>>>>>
>>>>>>> I'm thinking that the childAdded during the Console/Connection
>>>>>>> removal
>>>>>>> is
>>>>>>> a bug???
>>>>>>>
>>>>>>> Regards,
>>>>>>> Frase
>>>>>>>
>>>>>>>
>>>>>>> On 08/03/14 13:59, Rob Godfrey wrote:
>>>>>>>
>>>>>>>   OK - then that is probably more obvious to fix :-)
>>>>>>>
>>>>>>>> Just need to sort out one last thing with logging, then I'll get the
>>>>>>>> bindings and consumers working through the model (and write some
>>>>>>>> tests
>>>>>>>> to
>>>>>>>> catch this error for next time)
>>>>>>>>
>>>>>>>> -- Rob
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8 March 2014 14:50, Fraser Adams <fraser.ad...@blueyonder.co.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>    On 08/03/14 13:46, Rob Godfrey wrote:
>>>>>>>>
>>>>>>>>     Are the issues you are seeing just on Queue (i.e. getBindings()
>>>>>>>>> works ok
>>>>>>>>>
>>>>>>>>>  on
>>>>>>>>>> Exchange, getSubscriptions() works ok on sessions...)?
>>>>>>>>>>
>>>>>>>>>> I'll take a look in a sec... and once I isolate the problem
>>>>>>>>>> that'll
>>>>>>>>>> be
>>>>>>>>>> worth a few more tests so it doesn't slip through the net next
>>>>>>>>>> time...
>>>>>>>>>>
>>>>>>>>>> -- Rob
>>>>>>>>>>
>>>>>>>>>>    No sorry, I'm not seeing any child updates relating to
>>>>>>>>>> Bindings or
>>>>>>>>>>
>>>>>>>>>>  Subscriptions (Consumers)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    On 8 March 2014 14:40, Fraser Adams <
>>>>>>>>> fraser.ad...@blueyonder.co.uk>
>>>>>>>>>
>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>     Hey Rob,
>>>>>>>>>>
>>>>>>>>>>   Another issue I've had with the refactoring due to QPID-5578 <
>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/QPID-5578> is that I no
>>>>>>>>>>> longer
>>>>>>>>>>> see
>>>>>>>>>>> Binding and Subscription information.
>>>>>>>>>>>
>>>>>>>>>>> I use the ConfigurationChangeListener to synchronise the internal
>>>>>>>>>>> state
>>>>>>>>>>> and I strongly suspect that you've removed some of the
>>>>>>>>>>>
>>>>>>>>>>>                         childAdded(adapter); // Trigger
>>>>>>>>>>> corresponding
>>>>>>>>>>> ConfigurationChangeListener childAdded() callback.
>>>>>>>>>>>
>>>>>>>>>>> Stuff
>>>>>>>>>>>
>>>>>>>>>>> I don't have the *before carnage occurred* versions handy to
>>>>>>>>>>> check
>>>>>>>>>>> but
>>>>>>>>>>> my
>>>>>>>>>>> suspicion is that there used to be childAdded stuff in
>>>>>>>>>>> SessionAdapter.getConsumers()
>>>>>>>>>>>
>>>>>>>>>>> and also in the QueueAdapter.getBindings() and
>>>>>>>>>>> QueueAdapter.getConsumers()
>>>>>>>>>>>
>>>>>>>>>>> The QueueAdapter.getConsumers() seems to have its own issues
>>>>>>>>>>> hence
>>>>>>>>>>> the
>>>>>>>>>>> queue.getChildren(Consumer.class)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But the bottom line is that I don't believe that the
>>>>>>>>>>> ConfigurationChangeListener is getting correctly updated with the
>>>>>>>>>>> necessary
>>>>>>>>>>> state information!!
>>>>>>>>>>>
>>>>>>>>>>> Frase
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>>  To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>>>>>>>>>
>>>>>>>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to