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 :-)
On 9 March 2014 11:12, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>
>
>
> On 9 March 2014 10:57, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
>
>> 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
>>>
>>
> 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...
>
>
>> 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
>
> I'm about to check in a small change which is mainly a code tidy-up but
> might have led to spurious "extra" notifications... but it doesn't really
> explain what you are seeing above.
>
> -- Rob
>
>
>> 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
>>>
>>>
>
