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'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 :-) -- 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 > >