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 <[email protected]> wrote: > > > > On 8 March 2014 18:09, Fraser Adams <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> >>>>>>> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>> --------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
