Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

On 07/03/14 11:38, Rob Godfrey wrote:
> Hi Fraser,
>
> sorry - I had it on my list for today to look to see if any of the recent
> changes had broken the build for the QMF plugin...
>
> we really need to see if we can integrate the QMF plugin into the Jenkins
> builds or something so we get informed when it gets broken
>
> -- Rob
>
Hey Rob,
I'm going through it now. I'm starting with the Statistics stuff which 
seems reasonably straightforward to sort out.

I'll give you a yell if I tun into any issues - my first priority is to 
get the number of errors to a level where my eyes stop going fuzzy :-)

There seems to be a change to the main plugin bit where there used to be 
stuff relating to AVAILABLE_ATTRIBUTES I've not reached that bit yet, 
but if you've got any pointers to the changes around there and what 
needs to change that'd be a help.


It'd be good to get it into Jenkins, though I really wouldn't know where 
to begin with that.
Frase

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

It bugs me because in some ways I'd like to stop supporting building on 1.6
(it's been EOL'd by Oracle for a bit now) (albeit we'd still want to ensure
that the built jars would work under 1.6 - which in this case they would).
Fighting all the different versions of the compiler with their own
particular bugs is no fun at all :-(

Ultimately the getChildren(Class<? extends ConfiguredObject) is always
going to work on a ConfuguredObject... and the others are just convenience
methods to save typing.

-- Rob


On 7 March 2014 16:33, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> Might be worth adding a comment to org.apache.qpid.server.model.Queue to
> reflect this.
>
> did I mention comments.....
>
> Frase
>
>
> On 07/03/14 15:26, Rob Godfrey wrote:
>
>> .. and to answer myself for a third time... yes that was the issue
>>
>> both AMQQueue (the "implementation" interface) and Queue (the "model"
>> interface) define getConsumers(), with each returning a collection of
>> their
>> own brand of Consumers....
>>
>> AbstractQueue (the concrete implementation) implements both, and reutrns a
>> Collection of Consumer implementation objects which meets both these
>> definitions... and compiles fine in 1.7, but 1.6 barfs... Rather than try
>> to find a way of forcing the 1.6 compiler to work, I just removed from the
>> Queue interface as getChildren(Consumer.class) does the same thing and
>> getConsumers() was unused in the core codebase.
>>
>>
>> On 7 March 2014 16:13, Rob Godfrey <ro...@gmail.com> wrote:
>>
>>
>>>
>>> On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>>  Why have you removed getConsumers() from org.apache.qpid.server.model.
>>>> Queue?
>>>>
>>>> I was using that!
>>>>
>>>>                      for (Consumer subscription : queue.getConsumers())
>>>>                      {
>>>>                          childAdded(queue, subscription);
>>>>                      }
>>>>
>>>>
>>>> So in order to be able to navigate between a Connection and a Queue you
>>>> wind up with Connection, Session, Subscription (AKA Consumer) and
>>>> Queue. I
>>>> maintained the references between Session and Queue via Consumer e.g. in
>>>> childAdded() in QmfManagementAgent I do:
>>>>
>>>>
>>>>  You can do
>>>
>>> for(Consumer subscription : queue.getChildren(Consumer.class))
>>>
>>> I would think...
>>>
>>> Not sure why it got removed - probably just as it wasn't being
>>> referenced... although it might have been some sort of clash between the
>>> AMQQueue and Queue versions of getConsumers() causing issues when they
>>> merged their functions
>>>
>>> -- Rob
>>>
>>>           else if (child instanceof Consumer) // AKA Subscription
>>>>          {
>>>>              // Subscriptions are a little more complex because in QMF
>>>> Subscriptions contain sessionRef and queueRef
>>>>              // properties whereas with the Java Broker model Consumer
>>>> is
>>>> a child of Queue and Session. To cope with
>>>>              // this we first try to create or retrieve the QMF
>>>> Subscription Object then add either the Queue or
>>>>              // Session reference depending on whether Queue or Session
>>>> was the parent of this addChild() call.
>>>>              if (!_objects.containsKey(child))
>>>>              {
>>>>                  data = new org.apache.qpid.server.qmf2.
>>>> agentdata.Subscription((Consumer)child);
>>>>                  _objects.put(child, data);
>>>>             }
>>>>
>>>>              org.apache.qpid.server.qmf2.agentdata.Subscription
>>>> subscription =
>>>> (org.apache.qpid.server.qmf2.agentdata.Subscription)_
>>>> objects.get(child);
>>>>
>>>>              QmfAgentData ref = _objects.get(object);
>>>>              if (ref != null)
>>>>              {
>>>>                  if (object instanceof Queue)
>>>>                  {
>>>>                      subscription.setQueueRef(ref.getObjectId(),
>>>> (Queue)object);
>>>>                      // Raise a Subscribe Event - N.B. Need to do it
>>>> *after* we've set the queueRef.
>>>> _agent.raiseEvent(subscription.createSubscribeEvent());
>>>>                  }
>>>>                  else if (object instanceof Session)
>>>>                  {
>>>>                      subscription.setSessionRef(ref.getObjectId());
>>>>                  }
>>>>              }
>>>>          }
>>>>
>>>>
>>>> getConsumers() still seems to be present in AMQQueue.java and in
>>>> AbstractQueue.java so I hope that it was just "over zealous" tidying of
>>>> the
>>>> org.apache.qpid.server.model.Queue interface - I'd quite like to have
>>>> it
>>>> back please.
>>>>
>>>>
>>>> Frase
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

Might be worth adding a comment to org.apache.qpid.server.model.Queue to 
reflect this.

did I mention comments.....

Frase

On 07/03/14 15:26, Rob Godfrey wrote:
> .. and to answer myself for a third time... yes that was the issue
>
> both AMQQueue (the "implementation" interface) and Queue (the "model"
> interface) define getConsumers(), with each returning a collection of their
> own brand of Consumers....
>
> AbstractQueue (the concrete implementation) implements both, and reutrns a
> Collection of Consumer implementation objects which meets both these
> definitions... and compiles fine in 1.7, but 1.6 barfs... Rather than try
> to find a way of forcing the 1.6 compiler to work, I just removed from the
> Queue interface as getChildren(Consumer.class) does the same thing and
> getConsumers() was unused in the core codebase.
>
>
> On 7 March 2014 16:13, Rob Godfrey <ro...@gmail.com> wrote:
>
>>
>>
>> On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>>
>>> Why have you removed getConsumers() from org.apache.qpid.server.model.
>>> Queue?
>>>
>>> I was using that!
>>>
>>>                      for (Consumer subscription : queue.getConsumers())
>>>                      {
>>>                          childAdded(queue, subscription);
>>>                      }
>>>
>>>
>>> So in order to be able to navigate between a Connection and a Queue you
>>> wind up with Connection, Session, Subscription (AKA Consumer) and Queue. I
>>> maintained the references between Session and Queue via Consumer e.g. in
>>> childAdded() in QmfManagementAgent I do:
>>>
>>>
>> You can do
>>
>> for(Consumer subscription : queue.getChildren(Consumer.class))
>>
>> I would think...
>>
>> Not sure why it got removed - probably just as it wasn't being
>> referenced... although it might have been some sort of clash between the
>> AMQQueue and Queue versions of getConsumers() causing issues when they
>> merged their functions
>>
>> -- Rob
>>
>>>          else if (child instanceof Consumer) // AKA Subscription
>>>          {
>>>              // Subscriptions are a little more complex because in QMF
>>> Subscriptions contain sessionRef and queueRef
>>>              // properties whereas with the Java Broker model Consumer is
>>> a child of Queue and Session. To cope with
>>>              // this we first try to create or retrieve the QMF
>>> Subscription Object then add either the Queue or
>>>              // Session reference depending on whether Queue or Session
>>> was the parent of this addChild() call.
>>>              if (!_objects.containsKey(child))
>>>              {
>>>                  data = new org.apache.qpid.server.qmf2.
>>> agentdata.Subscription((Consumer)child);
>>>                  _objects.put(child, data);
>>>             }
>>>
>>>              org.apache.qpid.server.qmf2.agentdata.Subscription
>>> subscription =
>>> (org.apache.qpid.server.qmf2.agentdata.Subscription)_objects.get(child);
>>>
>>>              QmfAgentData ref = _objects.get(object);
>>>              if (ref != null)
>>>              {
>>>                  if (object instanceof Queue)
>>>                  {
>>>                      subscription.setQueueRef(ref.getObjectId(),
>>> (Queue)object);
>>>                      // Raise a Subscribe Event - N.B. Need to do it
>>> *after* we've set the queueRef.
>>> _agent.raiseEvent(subscription.createSubscribeEvent());
>>>                  }
>>>                  else if (object instanceof Session)
>>>                  {
>>>                      subscription.setSessionRef(ref.getObjectId());
>>>                  }
>>>              }
>>>          }
>>>
>>>
>>> getConsumers() still seems to be present in AMQQueue.java and in
>>> AbstractQueue.java so I hope that it was just "over zealous" tidying of the
>>> org.apache.qpid.server.model.Queue interface - I'd quite like to have it
>>> back please.
>>>
>>>
>>> Frase
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

On 9 March 2014 12:02, Fraser Adams <fr...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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

Cheers,
Frase


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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 <ro...@gmail.com> wrote:

>
>
>
> On 9 March 2014 10:57, Rob Godfrey <ro...@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" <fr...@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 <ro...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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.adams@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.adams@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-unsubscribe@qpid.apache.org
>>>>>>>>>>>>
>>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

On 9 March 2014 10:57, Rob Godfrey <ro...@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" <fr...@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?


> 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....



> 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...

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 <ro...@gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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.adams@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.adams@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-unsubscribe@qpid.apache.org
>>>>>>>>>>>
>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  ------------------------------------------------------------
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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" <fr...@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 <ro...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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 <fr...@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.adams@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-unsubscribe@qpid.apache.org
>>>>>>>>>>
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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 <ro...@gmail.com> wrote:
>>
>>>
>>>
>>> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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 <fr...@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 
>>>>>>>> <fr...@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-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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 <ro...@gmail.com> wrote:
>
>>
>>
>> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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 <ro...@gmail.com> wrote:

>
>
>
> On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ------------------------------------------------------------
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

On 8 March 2014 18:09, Fraser Adams <fr...@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 <fr...@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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>>>>  ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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

But it definitely seems pretty broken at the moment. Man that 
refactoring had me swearing a lot :-(

>
> 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

>
> -- Rob
>
> On 8 March 2014 15:19, Fraser Adams <fr...@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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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 <fr...@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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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 <fr...@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 <fr...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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 <fr...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

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


On 8 March 2014 14:40, Fraser Adams <fr...@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
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

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

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

.. and to answer myself for a third time... yes that was the issue

both AMQQueue (the "implementation" interface) and Queue (the "model"
interface) define getConsumers(), with each returning a collection of their
own brand of Consumers....

AbstractQueue (the concrete implementation) implements both, and reutrns a
Collection of Consumer implementation objects which meets both these
definitions... and compiles fine in 1.7, but 1.6 barfs... Rather than try
to find a way of forcing the 1.6 compiler to work, I just removed from the
Queue interface as getChildren(Consumer.class) does the same thing and
getConsumers() was unused in the core codebase.


On 7 March 2014 16:13, Rob Godfrey <ro...@gmail.com> wrote:

>
>
>
> On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> Why have you removed getConsumers() from org.apache.qpid.server.model.
>> Queue?
>>
>> I was using that!
>>
>>                     for (Consumer subscription : queue.getConsumers())
>>                     {
>>                         childAdded(queue, subscription);
>>                     }
>>
>>
>> So in order to be able to navigate between a Connection and a Queue you
>> wind up with Connection, Session, Subscription (AKA Consumer) and Queue. I
>> maintained the references between Session and Queue via Consumer e.g. in
>> childAdded() in QmfManagementAgent I do:
>>
>>
> You can do
>
> for(Consumer subscription : queue.getChildren(Consumer.class))
>
> I would think...
>
> Not sure why it got removed - probably just as it wasn't being
> referenced... although it might have been some sort of clash between the
> AMQQueue and Queue versions of getConsumers() causing issues when they
> merged their functions
>
> -- Rob
>
>>
>>         else if (child instanceof Consumer) // AKA Subscription
>>         {
>>             // Subscriptions are a little more complex because in QMF
>> Subscriptions contain sessionRef and queueRef
>>             // properties whereas with the Java Broker model Consumer is
>> a child of Queue and Session. To cope with
>>             // this we first try to create or retrieve the QMF
>> Subscription Object then add either the Queue or
>>             // Session reference depending on whether Queue or Session
>> was the parent of this addChild() call.
>>             if (!_objects.containsKey(child))
>>             {
>>                 data = new org.apache.qpid.server.qmf2.
>> agentdata.Subscription((Consumer)child);
>>                 _objects.put(child, data);
>>            }
>>
>>             org.apache.qpid.server.qmf2.agentdata.Subscription
>> subscription =
>> (org.apache.qpid.server.qmf2.agentdata.Subscription)_objects.get(child);
>>
>>             QmfAgentData ref = _objects.get(object);
>>             if (ref != null)
>>             {
>>                 if (object instanceof Queue)
>>                 {
>>                     subscription.setQueueRef(ref.getObjectId(),
>> (Queue)object);
>>                     // Raise a Subscribe Event - N.B. Need to do it
>> *after* we've set the queueRef.
>> _agent.raiseEvent(subscription.createSubscribeEvent());
>>                 }
>>                 else if (object instanceof Session)
>>                 {
>>                     subscription.setSessionRef(ref.getObjectId());
>>                 }
>>             }
>>         }
>>
>>
>> getConsumers() still seems to be present in AMQQueue.java and in
>> AbstractQueue.java so I hope that it was just "over zealous" tidying of the
>> org.apache.qpid.server.model.Queue interface - I'd quite like to have it
>> back please.
>>
>>
>> Frase
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

I'll set myself up a clean environment on a VM to see if I can get the
getConsumers() restored...  it may have been one of the things that the 1.6
compiler was getting upset about, despite working fine under 1.7...

-- Rob


On 7 March 2014 16:13, Rob Godfrey <ro...@gmail.com> wrote:

>
>
>
> On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> Why have you removed getConsumers() from org.apache.qpid.server.model.
>> Queue?
>>
>> I was using that!
>>
>>                     for (Consumer subscription : queue.getConsumers())
>>                     {
>>                         childAdded(queue, subscription);
>>                     }
>>
>>
>> So in order to be able to navigate between a Connection and a Queue you
>> wind up with Connection, Session, Subscription (AKA Consumer) and Queue. I
>> maintained the references between Session and Queue via Consumer e.g. in
>> childAdded() in QmfManagementAgent I do:
>>
>>
> You can do
>
> for(Consumer subscription : queue.getChildren(Consumer.class))
>
> I would think...
>
> Not sure why it got removed - probably just as it wasn't being
> referenced... although it might have been some sort of clash between the
> AMQQueue and Queue versions of getConsumers() causing issues when they
> merged their functions
>
> -- Rob
>
>>
>>         else if (child instanceof Consumer) // AKA Subscription
>>         {
>>             // Subscriptions are a little more complex because in QMF
>> Subscriptions contain sessionRef and queueRef
>>             // properties whereas with the Java Broker model Consumer is
>> a child of Queue and Session. To cope with
>>             // this we first try to create or retrieve the QMF
>> Subscription Object then add either the Queue or
>>             // Session reference depending on whether Queue or Session
>> was the parent of this addChild() call.
>>             if (!_objects.containsKey(child))
>>             {
>>                 data = new org.apache.qpid.server.qmf2.
>> agentdata.Subscription((Consumer)child);
>>                 _objects.put(child, data);
>>            }
>>
>>             org.apache.qpid.server.qmf2.agentdata.Subscription
>> subscription =
>> (org.apache.qpid.server.qmf2.agentdata.Subscription)_objects.get(child);
>>
>>             QmfAgentData ref = _objects.get(object);
>>             if (ref != null)
>>             {
>>                 if (object instanceof Queue)
>>                 {
>>                     subscription.setQueueRef(ref.getObjectId(),
>> (Queue)object);
>>                     // Raise a Subscribe Event - N.B. Need to do it
>> *after* we've set the queueRef.
>> _agent.raiseEvent(subscription.createSubscribeEvent());
>>                 }
>>                 else if (object instanceof Session)
>>                 {
>>                     subscription.setSessionRef(ref.getObjectId());
>>                 }
>>             }
>>         }
>>
>>
>> getConsumers() still seems to be present in AMQQueue.java and in
>> AbstractQueue.java so I hope that it was just "over zealous" tidying of the
>> org.apache.qpid.server.model.Queue interface - I'd quite like to have it
>> back please.
>>
>>
>> Frase
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

On 07/03/14 15:13, Rob Godfrey wrote:
> On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> Why have you removed getConsumers() from org.apache.qpid.server.model.
>> Queue?
>>
>> I was using that!
> You can do
>
> for(Consumer subscription : queue.getChildren(Consumer.class))
>
> I would think...
>
> Not sure why it got removed - probably just as it wasn't being
> referenced... although it might have been some sort of clash between the
> AMQQueue and Queue versions of getConsumers() causing issues when they
> merged their functions
>
Cheers, that seems to compile OK - I'll let you know if it actually 
works when I get it back running again, hopefully it'll be fine. I think 
I'm on the home strait now #famouslastwords

Frase

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

On 7 March 2014 16:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> Why have you removed getConsumers() from org.apache.qpid.server.model.
> Queue?
>
> I was using that!
>
>                     for (Consumer subscription : queue.getConsumers())
>                     {
>                         childAdded(queue, subscription);
>                     }
>
>
> So in order to be able to navigate between a Connection and a Queue you
> wind up with Connection, Session, Subscription (AKA Consumer) and Queue. I
> maintained the references between Session and Queue via Consumer e.g. in
> childAdded() in QmfManagementAgent I do:
>
>
You can do

for(Consumer subscription : queue.getChildren(Consumer.class))

I would think...

Not sure why it got removed - probably just as it wasn't being
referenced... although it might have been some sort of clash between the
AMQQueue and Queue versions of getConsumers() causing issues when they
merged their functions

-- Rob

>
>         else if (child instanceof Consumer) // AKA Subscription
>         {
>             // Subscriptions are a little more complex because in QMF
> Subscriptions contain sessionRef and queueRef
>             // properties whereas with the Java Broker model Consumer is a
> child of Queue and Session. To cope with
>             // this we first try to create or retrieve the QMF
> Subscription Object then add either the Queue or
>             // Session reference depending on whether Queue or Session was
> the parent of this addChild() call.
>             if (!_objects.containsKey(child))
>             {
>                 data = new org.apache.qpid.server.qmf2.
> agentdata.Subscription((Consumer)child);
>                 _objects.put(child, data);
>            }
>
>             org.apache.qpid.server.qmf2.agentdata.Subscription
> subscription =
> (org.apache.qpid.server.qmf2.agentdata.Subscription)_objects.get(child);
>
>             QmfAgentData ref = _objects.get(object);
>             if (ref != null)
>             {
>                 if (object instanceof Queue)
>                 {
>                     subscription.setQueueRef(ref.getObjectId(),
> (Queue)object);
>                     // Raise a Subscribe Event - N.B. Need to do it
> *after* we've set the queueRef.
> _agent.raiseEvent(subscription.createSubscribeEvent());
>                 }
>                 else if (object instanceof Session)
>                 {
>                     subscription.setSessionRef(ref.getObjectId());
>                 }
>             }
>         }
>
>
> getConsumers() still seems to be present in AMQQueue.java and in
> AbstractQueue.java so I hope that it was just "over zealous" tidying of the
> org.apache.qpid.server.model.Queue interface - I'd quite like to have it
> back please.
>
>
> Frase
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

Why have you removed getConsumers() from org.apache.qpid.server.model.Queue?

I was using that!

                     for (Consumer subscription : queue.getConsumers())
                     {
                         childAdded(queue, subscription);
                     }


So in order to be able to navigate between a Connection and a Queue you 
wind up with Connection, Session, Subscription (AKA Consumer) and Queue. 
I maintained the references between Session and Queue via Consumer e.g. 
in childAdded() in QmfManagementAgent I do:


         else if (child instanceof Consumer) // AKA Subscription
         {
             // Subscriptions are a little more complex because in QMF 
Subscriptions contain sessionRef and queueRef
             // properties whereas with the Java Broker model Consumer 
is a child of Queue and Session. To cope with
             // this we first try to create or retrieve the QMF 
Subscription Object then add either the Queue or
             // Session reference depending on whether Queue or Session 
was the parent of this addChild() call.
             if (!_objects.containsKey(child))
             {
                 data = new 
org.apache.qpid.server.qmf2.agentdata.Subscription((Consumer)child);
                 _objects.put(child, data);
            }

             org.apache.qpid.server.qmf2.agentdata.Subscription 
subscription =
(org.apache.qpid.server.qmf2.agentdata.Subscription)_objects.get(child);

             QmfAgentData ref = _objects.get(object);
             if (ref != null)
             {
                 if (object instanceof Queue)
                 {
                     subscription.setQueueRef(ref.getObjectId(), 
(Queue)object);
                     // Raise a Subscribe Event - N.B. Need to do it 
*after* we've set the queueRef.
_agent.raiseEvent(subscription.createSubscribeEvent());
                 }
                 else if (object instanceof Session)
                 {
                     subscription.setSessionRef(ref.getObjectId());
                 }
             }
         }


getConsumers() still seems to be present in AMQQueue.java and in 
AbstractQueue.java so I hope that it was just "over zealous" tidying of 
the org.apache.qpid.server.model.Queue interface - I'd quite like to 
have it back please.

Frase






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

Re my last message, I also noticed that if I did

     private final Broker<?> _broker; // Passed in by Plugin bootstrapping.

instead of

     private final Broker _broker; // Passed in by Plugin bootstrapping.

then
         for (VirtualHost vhost : _broker.getVirtualHosts())

seems to compile - I've got *no idea* what that's all about - would you 
be able to enlighten me?

Frase


On 07/03/14 13:43, Fraser Adams wrote:
> Hi again Rob,
> I'm a bit befuddled. I'm seeing a bunch of errors like:
>
>
>    [javac] 
> /home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:218: 
> incompatible types
>     [javac] found   : java.lang.Object
>     [javac] required: org.apache.qpid.server.model.VirtualHost
>     [javac]         for (VirtualHost vhost : _broker.getVirtualHosts())
> [javac]                                                         ^
>     [javac] 
> /home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:226: 
> incompatible types
>     [javac] found   : java.lang.Object
>     [javac] required: org.apache.qpid.server.model.Connection
>     [javac]             for (Connection connection : 
> vhost.getConnections())
> [javac] ^
>     [javac] 
> /home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:230: 
> incompatible types
>     [javac] found   : java.lang.Object
>     [javac] required: org.apache.qpid.server.model.Session
>     [javac]                 for (Session session : 
> connection.getSessions())
>     [javac]
>
>
> In code that had previously worked.
>
> The first bit of code looks like:
>
>         for (VirtualHost vhost : _broker.getVirtualHosts())
>         {
>
> Which seems fairly reasonable - I grepped in the Java Broker for 
> getVirtualHosts() and I'm seeing
>
>         VirtualHost<?> vhost = null;
>
>         for(VirtualHost vh : getBroker().getVirtualHosts())
>         {
>             if(vh.getName().equals(vhostName))
>             {
>                 vhost = vh;
>                 break;
>             }
>         }
>
> in MessageContentServlet.java - which looks essentially the same as 
> mine. Looking at the Broker model class I see:
>
>     Collection < VirtualHost<?> > getVirtualHosts();
>
> Is the <?> bit something new and is that my problem? To be honest my 
> Java generics knowledge doesn't go down to the level of <?>
>
>
> If I change
>         for (VirtualHost vhost : _broker.getVirtualHosts())
>         {
> to
>
>         for (VirtualHost vhost : 
> (java.util.Collection<VirtualHost>)_broker.getVirtualHosts())
>         {
>
> It compiles (though I've no idea if it would work correctly) but it 
> doesn't feel right especially since you seem to have "for(VirtualHost 
> vh : getBroker().getVirtualHosts())" working.
>
>
> Any idea what I'd need to change, it's all a bit crytic to me I'm afraid.
>
> Cheers,
> Frase
>
>
> On 07/03/14 11:54, Rob Godfrey wrote:
>> On 7 March 2014 12:47, Fraser Adams <fr...@blueyonder.co.uk> 
>> wrote:
>>
>>> On 07/03/14 11:38, Rob Godfrey wrote:
>>>
>>>> Hi Fraser,
>>>>
>>>> sorry - I had it on my list for today to look to see if any of the 
>>>> recent
>>>> changes had broken the build for the QMF plugin...
>>>>
>>>> we really need to see if we can integrate the QMF plugin into the 
>>>> Jenkins
>>>> builds or something so we get informed when it gets broken
>>>>
>>>> -- Rob
>>>>
>>>>   Hey Rob,
>>> I'm going through it now. I'm starting with the Statistics stuff which
>>> seems reasonably straightforward to sort out.
>>>
>>> I'll give you a yell if I tun into any issues - my first priority is to
>>> get the number of errors to a level where my eyes stop going fuzzy :-)
>>>
>>> There seems to be a change to the main plugin bit where there used 
>>> to be
>>> stuff relating to AVAILABLE_ATTRIBUTES I've not reached that bit 
>>> yet, but
>>> if you've got any pointers to the changes around there and what 
>>> needs to
>>> change that'd be a help.
>>>
>>>
>>>
>> So, if you are looking at a given instance of a ConfiguredObject you can
>> call Collection<String> getAttributeNames();
>>
>> If you want to know the available attributes for a given type of 
>> object you
>> can call     public static <X extends ConfiguredObject> 
>> Collection<String>
>> getAttributeNames(Class<X> clazz) on AbstractConfiguredObject,  so
>>
>> AbstractConfiguredObject.getAttributeNames(Queue.class);
>>
>> for instance.
>>
>> At some point in the near future there'll be sub-interfaces for 
>> different
>> types of things (e.g. PriorityQueue and LastValueQueue would have
>> additional attributes over Queue)...
>>
>> Apologies - I stupidly hadn't realised that your code was so 
>> dependent on
>> the constant String definitions of the attribute names
>>
>> -- Rob
>>
>>
>>
>>
>>> It'd be good to get it into Jenkins, though I really wouldn't know 
>>> where
>>> to begin with that.
>>> Frase
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Fraser Adams <fr...@blueyonder.co.uk>]

Hi again Rob,
I'm a bit befuddled. I'm seeing a bunch of errors like:


    [javac] 
/home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:218: 
incompatible types
     [javac] found   : java.lang.Object
     [javac] required: org.apache.qpid.server.model.VirtualHost
     [javac]         for (VirtualHost vhost : _broker.getVirtualHosts())
[javac]                                                         ^
     [javac] 
/home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:226: 
incompatible types
     [javac] found   : java.lang.Object
     [javac] required: org.apache.qpid.server.model.Connection
     [javac]             for (Connection connection : 
vhost.getConnections())
[javac] ^
     [javac] 
/home/fadams/qpid/qpid-trunk/qpid/tools/src/java/src/qpid-broker-plugins-management-qmf2/java/org/apache/qpid/server/qmf2/QmfManagementAgent.java:230: 
incompatible types
     [javac] found   : java.lang.Object
     [javac] required: org.apache.qpid.server.model.Session
     [javac]                 for (Session session : 
connection.getSessions())
     [javac]


In code that had previously worked.

The first bit of code looks like:

         for (VirtualHost vhost : _broker.getVirtualHosts())
         {

Which seems fairly reasonable - I grepped in the Java Broker for 
getVirtualHosts() and I'm seeing

         VirtualHost<?> vhost = null;

         for(VirtualHost vh : getBroker().getVirtualHosts())
         {
             if(vh.getName().equals(vhostName))
             {
                 vhost = vh;
                 break;
             }
         }

in MessageContentServlet.java - which looks essentially the same as 
mine. Looking at the Broker model class I see:

     Collection < VirtualHost<?> > getVirtualHosts();

Is the <?> bit something new and is that my problem? To be honest my 
Java generics knowledge doesn't go down to the level of <?>


If I change
         for (VirtualHost vhost : _broker.getVirtualHosts())
         {
to

         for (VirtualHost vhost : 
(java.util.Collection<VirtualHost>)_broker.getVirtualHosts())
         {

It compiles (though I've no idea if it would work correctly) but it 
doesn't feel right especially since you seem to have "for(VirtualHost vh 
: getBroker().getVirtualHosts())" working.


Any idea what I'd need to change, it's all a bit crytic to me I'm afraid.

Cheers,
Frase


On 07/03/14 11:54, Rob Godfrey wrote:
> On 7 March 2014 12:47, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> On 07/03/14 11:38, Rob Godfrey wrote:
>>
>>> Hi Fraser,
>>>
>>> sorry - I had it on my list for today to look to see if any of the recent
>>> changes had broken the build for the QMF plugin...
>>>
>>> we really need to see if we can integrate the QMF plugin into the Jenkins
>>> builds or something so we get informed when it gets broken
>>>
>>> -- Rob
>>>
>>>   Hey Rob,
>> I'm going through it now. I'm starting with the Statistics stuff which
>> seems reasonably straightforward to sort out.
>>
>> I'll give you a yell if I tun into any issues - my first priority is to
>> get the number of errors to a level where my eyes stop going fuzzy :-)
>>
>> There seems to be a change to the main plugin bit where there used to be
>> stuff relating to AVAILABLE_ATTRIBUTES I've not reached that bit yet, but
>> if you've got any pointers to the changes around there and what needs to
>> change that'd be a help.
>>
>>
>>
> So, if you are looking at a given instance of a ConfiguredObject you can
> call Collection<String> getAttributeNames();
>
> If you want to know the available attributes for a given type of object you
> can call     public static <X extends ConfiguredObject> Collection<String>
> getAttributeNames(Class<X> clazz) on AbstractConfiguredObject,  so
>
> AbstractConfiguredObject.getAttributeNames(Queue.class);
>
> for instance.
>
> At some point in the near future there'll be sub-interfaces for different
> types of things (e.g. PriorityQueue and LastValueQueue would have
> additional attributes over Queue)...
>
> Apologies - I stupidly hadn't realised that your code was so dependent on
> the constant String definitions of the attribute names
>
> -- Rob
>
>
>
>
>> It'd be good to get it into Jenkins, though I really wouldn't know where
>> to begin with that.
>> Frase
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management

[Rob Godfrey <ro...@gmail.com>]

On 7 March 2014 12:47, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> On 07/03/14 11:38, Rob Godfrey wrote:
>
>> Hi Fraser,
>>
>> sorry - I had it on my list for today to look to see if any of the recent
>> changes had broken the build for the QMF plugin...
>>
>> we really need to see if we can integrate the QMF plugin into the Jenkins
>> builds or something so we get informed when it gets broken
>>
>> -- Rob
>>
>>  Hey Rob,
> I'm going through it now. I'm starting with the Statistics stuff which
> seems reasonably straightforward to sort out.
>
> I'll give you a yell if I tun into any issues - my first priority is to
> get the number of errors to a level where my eyes stop going fuzzy :-)
>
> There seems to be a change to the main plugin bit where there used to be
> stuff relating to AVAILABLE_ATTRIBUTES I've not reached that bit yet, but
> if you've got any pointers to the changes around there and what needs to
> change that'd be a help.
>
>
>
So, if you are looking at a given instance of a ConfiguredObject you can
call Collection<String> getAttributeNames();

If you want to know the available attributes for a given type of object you
can call     public static <X extends ConfiguredObject> Collection<String>
getAttributeNames(Class<X> clazz) on AbstractConfiguredObject,  so

AbstractConfiguredObject.getAttributeNames(Queue.class);

for instance.

At some point in the near future there'll be sub-interfaces for different
types of things (e.g. PriorityQueue and LastValueQueue would have
additional attributes over Queue)...

Apologies - I stupidly hadn't realised that your code was so dependent on
the constant String definitions of the attribute names

-- Rob




> It'd be good to get it into Jenkins, though I really wouldn't know where
> to begin with that.
> Frase
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>