Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 254C0102BE for ; Sun, 9 Mar 2014 10:25:04 +0000 (UTC) Received: (qmail 88514 invoked by uid 500); 9 Mar 2014 10:25:03 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 88269 invoked by uid 500); 9 Mar 2014 10:25:02 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 88261 invoked by uid 99); 9 Mar 2014 10:25:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 09 Mar 2014 10:25:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com designates 209.85.216.178 as permitted sender) Received: from [209.85.216.178] (HELO mail-qc0-f178.google.com) (209.85.216.178) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 09 Mar 2014 10:24:53 +0000 Received: by mail-qc0-f178.google.com with SMTP id i8so6654537qcq.9 for ; Sun, 09 Mar 2014 03:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZT/NlKJB3+VgvdC8uhE81zQ2F4deu7R6rUSFwFFLSj4=; b=e0hhm7bQLAe0WEyxmh4ia1+dzuM082x8G1YxGFm7i6ULAKo5+3glUYoh50LJrQ+puB pvgI8Qp1rmv4GJqBykW7tsL7bmN9tFLi4rR6noGH7Ac+lYXjopU8D0wopw96rst3gqqJ v57kWcRnx2ZfSoxUka4J/HGf1szDtdftJFuL1/vMgvSUufvZhikrMtX2WhualGrCMPE5 nWMRkeMe8RYzJBBvD2iCMQA8TSoMsdUbbbIYqzhj9YSKXia2qkMFlk676FR2jfU4ljWn MB82oCLfHFTWG0oqQ99AWqbE9Q/Y7/keWIKqxNMBPBCTqq8Avzd+kWHljGD0wuS0v/T6 xmXQ== MIME-Version: 1.0 X-Received: by 10.229.241.9 with SMTP id lc9mr27355752qcb.15.1394360672515; Sun, 09 Mar 2014 03:24:32 -0700 (PDT) Received: by 10.140.109.100 with HTTP; Sun, 9 Mar 2014 03:24:32 -0700 (PDT) In-Reply-To: References: <5BDF75D02AC1DB4C9DF96C0D0EB948BAABA3857D@PDCEXC001.prague.wood.cz> <5319911A.4000805@blueyonder.co.uk> <5319B1E3.8010709@blueyonder.co.uk> <5319E0B7.1010202@blueyonder.co.uk> <531B1DD2.6000808@blueyonder.co.uk> <531B203D.5040801@blueyonder.co.uk> <531B2705.7080100@blueyonder.co.uk> <531B4EBD.7060003@blueyonder.co.uk> <531B7C93.5060208@blueyonder.co.uk> <531C32C3.8080309@blueyonder.co.uk> Date: Sun, 9 Mar 2014 11:24:32 +0100 Message-ID: Subject: Re: Java Broker plugin change - was Re: QPID C++ broker monitoring and management From: Rob Godfrey To: "users@qpid.apache.org" Content-Type: multipart/alternative; boundary=001a11348a4092fb3604f429e4d0 X-Virus-Checked: Checked by ClamAV on apache.org --001a11348a4092fb3604f429e4d0 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > > > On 9 March 2014 10:57, Rob Godfrey 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" >> 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 wrote: >>>>> >>>>> >>>>>> >>>>>> On 8 March 2014 18:09, Fraser Adams >>>>>> 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 >>>>>>>> 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: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>> >>> > --001a11348a4092fb3604f429e4d0--