You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jan Bares <ja...@wood.cz> on 2014/03/04 09:48:11 UTC
QPID C++ broker monitoring and management
Hi,
Which tools do you use for monitoring? I would like to use something like Zabbix (www.zabbix.com) for QPID monitoring, should I use the command line tool like qpid-stat to gather statistics or is there better option? And what do you monitor? This pops out of my mind (besides log):
* lingering messages in queue (e.g. consumer is dead)
* messages in dead letter queue
* number of messages over time period
Is there any GUI based (web based) QPID management tool? I was looking at QMF and I have to say I don't understand what this tool doe. It seems like Java's JMX or other management tools without ready to use agents or GUI. Did not found any documentation of console.py in the QMF download.
Thank you for your time, Jan
Jan Bareš
Calypso Lead Developer
In association with
WOOD & Company Financial Services, a.s.
Palladium, Náměstí Republiky 1079/1a
110 00 Prague, Czech Republic
Tel. +420 222 096 111
Direct +420 222 096 457
Fax. +420 222 096 222
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Rob Godfrey <ro...@gmail.com>.
Or, of you wanted to be all UNIXy about it you could do
svn propset svn:eol-style LF `find . -name '*.sh'`
from within tools/src/java :-)
-- Rob
On 10 March 2014 21:40, Rob Godfrey <ro...@gmail.com> wrote:
> yep... that's about it
>
> -- Rob
>
>
> On 10 March 2014 21:31, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> So am I correct in thinking that I'd need to do something like:
>>
>> |svn propset svn:eol-style LF <filename>|
>>
>> For all of the *.sh files then recommit?
>>
>> 'fraid I'm not especially familiar with the nuances of subversion
>>
>> Frase
>>
>>
>> On 10/03/14 18:52, Robbie Gemmell wrote:
>>
>>> Read the link Rob sent and all should be clear.
>>>
>>> Robbie
>>>
>>> On 10 March 2014 18:01, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>> You've just confused me now Rob.
>>>> From what I can tell I've saved these files with UNIX style "\n" (0x0A)
>>>> line endings and I'm using the standard Linux svn client so I doubt
>>>> that's
>>>> nobbling them into Windows style.
>>>>
>>>> I thought that your earlier mail was suggesting that Jan might have been
>>>> using the Windows svn client and it was likely that which is converting
>>>> the
>>>> end of lines.
>>>>
>>>> So I'm not really sure what you are saying TBH
>>>> Frase
>>>>
>>>>
>>>>
>>>> On 10/03/14 17:39, Rob Godfrey wrote:
>>>>
>>>> Given that these are .sh files, I think it reasonable for us to change
>>>>> them
>>>>> to have LF eol-style in subversion... I'd imagine anything that ran on
>>>>> windows that emulated a UNIX shell would handle files UNIX style line
>>>>> endings, and it would make life easier for people using Cygwin by the
>>>>> sounds of things.
>>>>>
>>>>> -- Rob
>>>>>
>>>>>
>>>>> On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk>
>>>>> wrote:
>>>>>
>>>>> Thanks Rob, that would be my guess too. I've just checked on gedit
>>>>> and if
>>>>>
>>>>>> you do
>>>>>> file->save as
>>>>>>
>>>>>> It gives you an option Line Ending and the default is Unix/Linux when
>>>>>> I
>>>>>> hit save there there was no change to what I had previously so I'm
>>>>>> pretty
>>>>>> sure that I'm saving with Unix file endings.
>>>>>>
>>>>>> Just checked with a hex editor too and I'm just seeing 0x0A, so I
>>>>>> think
>>>>>> that what you are suggesting would seem about right.
>>>>>>
>>>>>> Frase
>>>>>>
>>>>>>
>>>>>> On 10/03/14 17:10, Rob Godfrey wrote:
>>>>>>
>>>>>> Is this a function of whichever svn client Jan is using under cygwin
>>>>>>
>>>>>>> assuming that "native" eol-style[1] for that platform is CRLF rather
>>>>>>> than
>>>>>>> LF.
>>>>>>>
>>>>>>> Given the files wouldn't normally work under windows except under
>>>>>>> Cygwin
>>>>>>> perhaps changing the svn:eol-style of the .sh files to LF (rather
>>>>>>> than
>>>>>>> native as they are currently)?
>>>>>>>
>>>>>>> -- Rob
>>>>>>>
>>>>>>> [1]
>>>>>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>>>>>>> file-portability.html#svn.advanced.props.special.eol-style
>>>>>>>
>>>>>>>
>>>>>>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> I have to say that I don't really understand what you are getting at
>>>>>>>> with
>>>>>>>> some of these comments - especially "Is there any reason why you use
>>>>>>>> Windows line endings?"
>>>>>>>>
>>>>>>>> I'm using a Linux box - always have done. I generally use gedit on
>>>>>>>> Linux
>>>>>>>> to edit and these scripts are no exception.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/03/14 09:31, Jan Bares wrote:
>>>>>>>>
>>>>>>>> Hi Fraser,
>>>>>>>>
>>>>>>>> Thank you for the change, it works fine, I just have to convert to
>>>>>>>>> Unix
>>>>>>>>> line endings. Yes, the cygpath must be called before you use it.
>>>>>>>>> What
>>>>>>>>> I
>>>>>>>>> meant was to keep just the Cygwin detection code at the script
>>>>>>>>> begin.
>>>>>>>>> Is
>>>>>>>>> there any reason why you use Windows line endings? I do not have
>>>>>>>>> deep
>>>>>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support
>>>>>>>>> inside,
>>>>>>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>>>>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log
>>>>>>>>> .
>>>>>>>>> There you can also see support for Darwin and os400 embedded.
>>>>>>>>>
>>>>>>>>> Thanks you, Jan
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>>
>>>>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>>>>>>
>>>>>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>>>>>>
>>>>>>>>>> Hi Jan,
>>>>>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you
>>>>>>>>>> please
>>>>>>>>>> check to see if that works and give me a yell. If it works then
>>>>>>>>>> I'll
>>>>>>>>>> update the other scripts.
>>>>>>>>>>
>>>>>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>>>>>>
>>>>>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>>>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>>>>>>
>>>>>>>>>> myself because the qpid-client-patch.jar gets put *before* the
>>>>>>>>>> main
>>>>>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit
>>>>>>>>>> quirky
>>>>>>>>>> but that patch is an optional thing for people running < Qpid
>>>>>>>>>> 0.12 it
>>>>>>>>>> provides a "patch" to one of the classes on that to enable the
>>>>>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF
>>>>>>>>>> (see
>>>>>>>>>> the README.txt)
>>>>>>>>>>
>>>>>>>>>> Hopefully nobody is using that stuff now, but you never know :-)
>>>>>>>>>> but
>>>>>>>>>> given that I *think* that I need to add your:
>>>>>>>>>>
>>>>>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>>>>>>
>>>>>>>>>> After I've set the CLASSPATH.
>>>>>>>>>>
>>>>>>>>>> Just in case you are wondering why I didn't just shove the Cygwin
>>>>>>>>>> block
>>>>>>>>>> at the start.
>>>>>>>>>>
>>>>>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Frase
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DISCLAIMER
>>>>>>>>>>
>>>>>>>>> ________________________________
>>>>>>>>> WOOD & Company Financial Services, a.s. and its
>>>>>>>>> branches
>>>>>>>>> are
>>>>>>>>> authorized and regulated by the CNB as Home State regulator and in
>>>>>>>>> Poland
>>>>>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>>>>>>> State
>>>>>>>>> regulators. For further information about WOOD & Co., its
>>>>>>>>> investment
>>>>>>>>> services, financial instruments and associated risks, safeguard
>>>>>>>>> client
>>>>>>>>> assets (incl. compensation schemes) and contractual relationship
>>>>>>>>> please
>>>>>>>>> see
>>>>>>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>>>>>>> Corporate Governance.
>>>>>>>>> Unless otherwise stated, this transmission is neither
>>>>>>>>> an
>>>>>>>>> offer
>>>>>>>>> nor the solicitation of an offer to sell or purchase any
>>>>>>>>> investment.
>>>>>>>>> All
>>>>>>>>> estimates, opinions and other information contained herein are
>>>>>>>>> subject
>>>>>>>>> to
>>>>>>>>> change without notice and are provided in good faith but without
>>>>>>>>> legal
>>>>>>>>> responsibility or liability. Opinion may be personal to the author
>>>>>>>>> and
>>>>>>>>> may
>>>>>>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>>>>>>> persons,
>>>>>>>>> sales traders or traders should not be regarded as investment
>>>>>>>>> research
>>>>>>>>> and
>>>>>>>>> may contain opinions or trading ideas which are different from
>>>>>>>>> WOOD &
>>>>>>>>> Co.
>>>>>>>>> investment research opinions.
>>>>>>>>> This e-mail and any attachments are confidential and
>>>>>>>>> may
>>>>>>>>> be
>>>>>>>>> privileged or otherwise protected from disclosure. If you are not a
>>>>>>>>> named
>>>>>>>>> addressee you must not use, disclose, distribute, copy, print or
>>>>>>>>> rely
>>>>>>>>> on
>>>>>>>>> this e-mail and any of its attachments. Please notify the sender
>>>>>>>>> that
>>>>>>>>> you
>>>>>>>>> have received this email by mistake by replying to the email, and
>>>>>>>>> then
>>>>>>>>> delete the email and any copies of it. Although WOOD & Co.
>>>>>>>>> routinely
>>>>>>>>> screens e-mails for viruses, addressees should scan this e-mail and
>>>>>>>>> any
>>>>>>>>> attachments for viruses. WOOD & Co. makes no representation or
>>>>>>>>> warranty
>>>>>>>>> as
>>>>>>>>> to the absence of viruses in this e-mail or any attachments. Please
>>>>>>>>> note
>>>>>>>>> that to ensure regulatory compliance and for the protection of our
>>>>>>>>> clients
>>>>>>>>> and business, we may monitor and read e-mails sent to and from our
>>>>>>>>> server(s).
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> 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: QPID C++ broker monitoring and management
Posted by Rob Godfrey <ro...@gmail.com>.
yep... that's about it
-- Rob
On 10 March 2014 21:31, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> So am I correct in thinking that I'd need to do something like:
>
> |svn propset svn:eol-style LF <filename>|
>
> For all of the *.sh files then recommit?
>
> 'fraid I'm not especially familiar with the nuances of subversion
>
> Frase
>
>
> On 10/03/14 18:52, Robbie Gemmell wrote:
>
>> Read the link Rob sent and all should be clear.
>>
>> Robbie
>>
>> On 10 March 2014 18:01, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>> You've just confused me now Rob.
>>> From what I can tell I've saved these files with UNIX style "\n" (0x0A)
>>> line endings and I'm using the standard Linux svn client so I doubt
>>> that's
>>> nobbling them into Windows style.
>>>
>>> I thought that your earlier mail was suggesting that Jan might have been
>>> using the Windows svn client and it was likely that which is converting
>>> the
>>> end of lines.
>>>
>>> So I'm not really sure what you are saying TBH
>>> Frase
>>>
>>>
>>>
>>> On 10/03/14 17:39, Rob Godfrey wrote:
>>>
>>> Given that these are .sh files, I think it reasonable for us to change
>>>> them
>>>> to have LF eol-style in subversion... I'd imagine anything that ran on
>>>> windows that emulated a UNIX shell would handle files UNIX style line
>>>> endings, and it would make life easier for people using Cygwin by the
>>>> sounds of things.
>>>>
>>>> -- Rob
>>>>
>>>>
>>>> On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk>
>>>> wrote:
>>>>
>>>> Thanks Rob, that would be my guess too. I've just checked on gedit
>>>> and if
>>>>
>>>>> you do
>>>>> file->save as
>>>>>
>>>>> It gives you an option Line Ending and the default is Unix/Linux when I
>>>>> hit save there there was no change to what I had previously so I'm
>>>>> pretty
>>>>> sure that I'm saving with Unix file endings.
>>>>>
>>>>> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
>>>>> that what you are suggesting would seem about right.
>>>>>
>>>>> Frase
>>>>>
>>>>>
>>>>> On 10/03/14 17:10, Rob Godfrey wrote:
>>>>>
>>>>> Is this a function of whichever svn client Jan is using under cygwin
>>>>>
>>>>>> assuming that "native" eol-style[1] for that platform is CRLF rather
>>>>>> than
>>>>>> LF.
>>>>>>
>>>>>> Given the files wouldn't normally work under windows except under
>>>>>> Cygwin
>>>>>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
>>>>>> native as they are currently)?
>>>>>>
>>>>>> -- Rob
>>>>>>
>>>>>> [1]
>>>>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>>>>>> file-portability.html#svn.advanced.props.special.eol-style
>>>>>>
>>>>>>
>>>>>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> I have to say that I don't really understand what you are getting at
>>>>>>> with
>>>>>>> some of these comments - especially "Is there any reason why you use
>>>>>>> Windows line endings?"
>>>>>>>
>>>>>>> I'm using a Linux box - always have done. I generally use gedit on
>>>>>>> Linux
>>>>>>> to edit and these scripts are no exception.
>>>>>>>
>>>>>>>
>>>>>>> On 10/03/14 09:31, Jan Bares wrote:
>>>>>>>
>>>>>>> Hi Fraser,
>>>>>>>
>>>>>>> Thank you for the change, it works fine, I just have to convert to
>>>>>>>> Unix
>>>>>>>> line endings. Yes, the cygpath must be called before you use it.
>>>>>>>> What
>>>>>>>> I
>>>>>>>> meant was to keep just the Cygwin detection code at the script
>>>>>>>> begin.
>>>>>>>> Is
>>>>>>>> there any reason why you use Windows line endings? I do not have
>>>>>>>> deep
>>>>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support
>>>>>>>> inside,
>>>>>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>>>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>>>>>>> There you can also see support for Darwin and os400 embedded.
>>>>>>>>
>>>>>>>> Thanks you, Jan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>
>>>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>>>>>
>>>>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>>>>>> To: users@qpid.apache.org
>>>>>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you
>>>>>>>>> please
>>>>>>>>> check to see if that works and give me a yell. If it works then
>>>>>>>>> I'll
>>>>>>>>> update the other scripts.
>>>>>>>>>
>>>>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>>>>>
>>>>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>>>>>
>>>>>>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit
>>>>>>>>> quirky
>>>>>>>>> but that patch is an optional thing for people running < Qpid 0.12
>>>>>>>>> it
>>>>>>>>> provides a "patch" to one of the classes on that to enable the
>>>>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF
>>>>>>>>> (see
>>>>>>>>> the README.txt)
>>>>>>>>>
>>>>>>>>> Hopefully nobody is using that stuff now, but you never know :-)
>>>>>>>>> but
>>>>>>>>> given that I *think* that I need to add your:
>>>>>>>>>
>>>>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>>>>>
>>>>>>>>> After I've set the CLASSPATH.
>>>>>>>>>
>>>>>>>>> Just in case you are wondering why I didn't just shove the Cygwin
>>>>>>>>> block
>>>>>>>>> at the start.
>>>>>>>>>
>>>>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Frase
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> DISCLAIMER
>>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>> WOOD & Company Financial Services, a.s. and its
>>>>>>>> branches
>>>>>>>> are
>>>>>>>> authorized and regulated by the CNB as Home State regulator and in
>>>>>>>> Poland
>>>>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>>>>>> State
>>>>>>>> regulators. For further information about WOOD & Co., its investment
>>>>>>>> services, financial instruments and associated risks, safeguard
>>>>>>>> client
>>>>>>>> assets (incl. compensation schemes) and contractual relationship
>>>>>>>> please
>>>>>>>> see
>>>>>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>>>>>> Corporate Governance.
>>>>>>>> Unless otherwise stated, this transmission is neither
>>>>>>>> an
>>>>>>>> offer
>>>>>>>> nor the solicitation of an offer to sell or purchase any investment.
>>>>>>>> All
>>>>>>>> estimates, opinions and other information contained herein are
>>>>>>>> subject
>>>>>>>> to
>>>>>>>> change without notice and are provided in good faith but without
>>>>>>>> legal
>>>>>>>> responsibility or liability. Opinion may be personal to the author
>>>>>>>> and
>>>>>>>> may
>>>>>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>>>>>> persons,
>>>>>>>> sales traders or traders should not be regarded as investment
>>>>>>>> research
>>>>>>>> and
>>>>>>>> may contain opinions or trading ideas which are different from WOOD
>>>>>>>> &
>>>>>>>> Co.
>>>>>>>> investment research opinions.
>>>>>>>> This e-mail and any attachments are confidential and
>>>>>>>> may
>>>>>>>> be
>>>>>>>> privileged or otherwise protected from disclosure. If you are not a
>>>>>>>> named
>>>>>>>> addressee you must not use, disclose, distribute, copy, print or
>>>>>>>> rely
>>>>>>>> on
>>>>>>>> this e-mail and any of its attachments. Please notify the sender
>>>>>>>> that
>>>>>>>> you
>>>>>>>> have received this email by mistake by replying to the email, and
>>>>>>>> then
>>>>>>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>>>>>>> screens e-mails for viruses, addressees should scan this e-mail and
>>>>>>>> any
>>>>>>>> attachments for viruses. WOOD & Co. makes no representation or
>>>>>>>> warranty
>>>>>>>> as
>>>>>>>> to the absence of viruses in this e-mail or any attachments. Please
>>>>>>>> note
>>>>>>>> that to ensure regulatory compliance and for the protection of our
>>>>>>>> clients
>>>>>>>> and business, we may monitor and read e-mails sent to and from our
>>>>>>>> server(s).
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
Hi Fraser, Rob and Robbie,
I am sorry for the confusion and your precious time, I should have known its SVN platform issue :-). Yes, I use Windows SVN client, so I get the windows line endings on checkout. Fraser, your last commit is just fine, now it works without any modifications. Just last small nitpick, the comment "If we're on Cygwin we need to prepend the CLASSPATH with cygpath." is not accurate. The cygpath [*] converts Unix path to windows path:
Before cygpath:
/cygdrive/c/Programs.Java/RedHat/qpid/qpid-qmf-gui/qpid-qmf-gui-trunk/build/lib/qpid-client-patch.jar:../../qpid/lib/*:/cygdrive/c/Programs.Java/RedHat/qpid/qpid-qmf-gui/qpid-qmf-gui-trunk/build/lib/qmf2.jar:/cygdrive/c/Programs.Java/RedHat/qpid/qpid-qmf-gui/qpid-qmf-gui-trunk/build/lib/restapi.jar
Cygpath returns:
C:\Programs.Java\RedHat\qpid\qpid-qmf-gui\qpid-qmf-gui-trunk\build\lib\qpid-client-patch.jar;C:\Programs.Java\RedHat\qpid\qpid-qmf-gui\qpid\lib\*;C:\Programs.Java\RedHat\qpid\qpid-qmf-gui\qpid-qmf-gui-trunk\build\lib\qmf2.jar;C:\Programs.Java\RedHat\qpid\qpid-qmf-gui\qpid-qmf-gui-trunk\build\lib\restapi.jar
As you can see, the path is converted to Windows path and also the classpath separator ":" is converted to windows classpath separator ";". So I suggest to comment like: "On Cygwin convert to Windows path" or no comment at all as this is clear from the code.
Many thanks, Jan
[*] http://cygwin.com/cygwin-ug-net/using-utils.html#cygpath
> -----Original Message-----
> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> Sent: Monday, March 10, 2014 9:31 PM
> To: users@qpid.apache.org
> Subject: Re: QPID C++ broker monitoring and management
>
> So am I correct in thinking that I'd need to do something like:
>
> |svn propset svn:eol-style LF <filename>|
>
> For all of the *.sh files then recommit?
>
> 'fraid I'm not especially familiar with the nuances of subversion
>
> Frase
>
> On 10/03/14 18:52, Robbie Gemmell wrote:
> > Read the link Rob sent and all should be clear.
> >
> > Robbie
> >
> > On 10 March 2014 18:01, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
> >
> >> You've just confused me now Rob.
> >> From what I can tell I've saved these files with UNIX style "\n" (0x0A)
> >> line endings and I'm using the standard Linux svn client so I doubt that's
> >> nobbling them into Windows style.
> >>
> >> I thought that your earlier mail was suggesting that Jan might have been
> >> using the Windows svn client and it was likely that which is converting the
> >> end of lines.
> >>
> >> So I'm not really sure what you are saying TBH
> >> Frase
> >>
> >>
> >>
> >> On 10/03/14 17:39, Rob Godfrey wrote:
> >>
> >>> Given that these are .sh files, I think it reasonable for us to change
> >>> them
> >>> to have LF eol-style in subversion... I'd imagine anything that ran on
> >>> windows that emulated a UNIX shell would handle files UNIX style line
> >>> endings, and it would make life easier for people using Cygwin by the
> >>> sounds of things.
> >>>
> >>> -- Rob
> >>>
> >>>
> >>> On 10 March 2014 18:25, Fraser Adams
> <fr...@blueyonder.co.uk>
> >>> wrote:
> >>>
> >>> Thanks Rob, that would be my guess too. I've just checked on gedit and
> if
> >>>> you do
> >>>> file->save as
> >>>>
> >>>> It gives you an option Line Ending and the default is Unix/Linux when I
> >>>> hit save there there was no change to what I had previously so I'm
> pretty
> >>>> sure that I'm saving with Unix file endings.
> >>>>
> >>>> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
> >>>> that what you are suggesting would seem about right.
> >>>>
> >>>> Frase
> >>>>
> >>>>
> >>>> On 10/03/14 17:10, Rob Godfrey wrote:
> >>>>
> >>>> Is this a function of whichever svn client Jan is using under cygwin
> >>>>> assuming that "native" eol-style[1] for that platform is CRLF rather
> >>>>> than
> >>>>> LF.
> >>>>>
> >>>>> Given the files wouldn't normally work under windows except under
> Cygwin
> >>>>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
> >>>>> native as they are currently)?
> >>>>>
> >>>>> -- Rob
> >>>>>
> >>>>> [1]
> >>>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
> >>>>> file-portability.html#svn.advanced.props.special.eol-style
> >>>>>
> >>>>>
> >>>>> On 10 March 2014 18:00, Fraser Adams
> <fr...@blueyonder.co.uk>
> >>>>> wrote:
> >>>>>
> >>>>> Hi Jan,
> >>>>>
> >>>>>> I have to say that I don't really understand what you are getting at
> >>>>>> with
> >>>>>> some of these comments - especially "Is there any reason why you
> use
> >>>>>> Windows line endings?"
> >>>>>>
> >>>>>> I'm using a Linux box - always have done. I generally use gedit on
> >>>>>> Linux
> >>>>>> to edit and these scripts are no exception.
> >>>>>>
> >>>>>>
> >>>>>> On 10/03/14 09:31, Jan Bares wrote:
> >>>>>>
> >>>>>> Hi Fraser,
> >>>>>>
> >>>>>>> Thank you for the change, it works fine, I just have to convert to
> >>>>>>> Unix
> >>>>>>> line endings. Yes, the cygpath must be called before you use it.
> What
> >>>>>>> I
> >>>>>>> meant was to keep just the Cygwin detection code at the script
> begin.
> >>>>>>> Is
> >>>>>>> there any reason why you use Windows line endings? I do not have
> deep
> >>>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support
> >>>>>>> inside,
> >>>>>>> such as Tomcat catalina.sh, use Unix line endings. See
> >>>>>>>
> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
> >>>>>>> There you can also see support for Darwin and os400 embedded.
> >>>>>>>
> >>>>>>> Thanks you, Jan
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>>
> >>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> >>>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
> >>>>>>>> To: users@qpid.apache.org
> >>>>>>>> Subject: Re: QPID C++ broker monitoring and management
> >>>>>>>>
> >>>>>>>> Hi Jan,
> >>>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you
> please
> >>>>>>>> check to see if that works and give me a yell. If it works then I'll
> >>>>>>>> update the other scripts.
> >>>>>>>>
> >>>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
> >>>>>>>>
> >>>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
> >>>>>>>>
> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
> >>>>>>>>
> >>>>>>>> myself because the qpid-client-patch.jar gets put *before* the
> main
> >>>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit
> quirky
> >>>>>>>> but that patch is an optional thing for people running < Qpid 0.12 it
> >>>>>>>> provides a "patch" to one of the classes on that to enable the
> >>>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for
> QMF
> >>>>>>>> (see
> >>>>>>>> the README.txt)
> >>>>>>>>
> >>>>>>>> Hopefully nobody is using that stuff now, but you never know :-)
> but
> >>>>>>>> given that I *think* that I need to add your:
> >>>>>>>>
> >>>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
> >>>>>>>>
> >>>>>>>> After I've set the CLASSPATH.
> >>>>>>>>
> >>>>>>>> Just in case you are wondering why I didn't just shove the Cygwin
> >>>>>>>> block
> >>>>>>>> at the start.
> >>>>>>>>
> >>>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Frase
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> DISCLAIMER
> >>>>>>> ________________________________
> >>>>>>> WOOD & Company Financial Services, a.s. and its branches
> >>>>>>> are
> >>>>>>> authorized and regulated by the CNB as Home State regulator and
> in
> >>>>>>> Poland
> >>>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
> >>>>>>> State
> >>>>>>> regulators. For further information about WOOD & Co., its
> investment
> >>>>>>> services, financial instruments and associated risks, safeguard client
> >>>>>>> assets (incl. compensation schemes) and contractual relationship
> >>>>>>> please
> >>>>>>> see
> >>>>>>> our website at www.wood.com<http://www.wood.com/> under
> section
> >>>>>>> Corporate Governance.
> >>>>>>> Unless otherwise stated, this transmission is neither an
> >>>>>>> offer
> >>>>>>> nor the solicitation of an offer to sell or purchase any investment.
> >>>>>>> All
> >>>>>>> estimates, opinions and other information contained herein are
> subject
> >>>>>>> to
> >>>>>>> change without notice and are provided in good faith but without
> legal
> >>>>>>> responsibility or liability. Opinion may be personal to the author and
> >>>>>>> may
> >>>>>>> not reflect the opinions of WOOD & Co. Communications from sales
> >>>>>>> persons,
> >>>>>>> sales traders or traders should not be regarded as investment
> research
> >>>>>>> and
> >>>>>>> may contain opinions or trading ideas which are different from
> WOOD &
> >>>>>>> Co.
> >>>>>>> investment research opinions.
> >>>>>>> This e-mail and any attachments are confidential and may
> >>>>>>> be
> >>>>>>> privileged or otherwise protected from disclosure. If you are not a
> >>>>>>> named
> >>>>>>> addressee you must not use, disclose, distribute, copy, print or rely
> >>>>>>> on
> >>>>>>> this e-mail and any of its attachments. Please notify the sender that
> >>>>>>> you
> >>>>>>> have received this email by mistake by replying to the email, and
> then
> >>>>>>> delete the email and any copies of it. Although WOOD & Co.
> routinely
> >>>>>>> screens e-mails for viruses, addressees should scan this e-mail and
> >>>>>>> any
> >>>>>>> attachments for viruses. WOOD & Co. makes no representation or
> >>>>>>> warranty
> >>>>>>> as
> >>>>>>> to the absence of viruses in this e-mail or any attachments. Please
> >>>>>>> note
> >>>>>>> that to ensure regulatory compliance and for the protection of our
> >>>>>>> clients
> >>>>>>> and business, we may monitor and read e-mails sent to and from
> our
> >>>>>>> server(s).
> >>>>>>> ________________________________
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> 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
> >>
> >>
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
So am I correct in thinking that I'd need to do something like:
|svn propset svn:eol-style LF <filename>|
For all of the *.sh files then recommit?
'fraid I'm not especially familiar with the nuances of subversion
Frase
On 10/03/14 18:52, Robbie Gemmell wrote:
> Read the link Rob sent and all should be clear.
>
> Robbie
>
> On 10 March 2014 18:01, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> You've just confused me now Rob.
>> From what I can tell I've saved these files with UNIX style "\n" (0x0A)
>> line endings and I'm using the standard Linux svn client so I doubt that's
>> nobbling them into Windows style.
>>
>> I thought that your earlier mail was suggesting that Jan might have been
>> using the Windows svn client and it was likely that which is converting the
>> end of lines.
>>
>> So I'm not really sure what you are saying TBH
>> Frase
>>
>>
>>
>> On 10/03/14 17:39, Rob Godfrey wrote:
>>
>>> Given that these are .sh files, I think it reasonable for us to change
>>> them
>>> to have LF eol-style in subversion... I'd imagine anything that ran on
>>> windows that emulated a UNIX shell would handle files UNIX style line
>>> endings, and it would make life easier for people using Cygwin by the
>>> sounds of things.
>>>
>>> -- Rob
>>>
>>>
>>> On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>> Thanks Rob, that would be my guess too. I've just checked on gedit and if
>>>> you do
>>>> file->save as
>>>>
>>>> It gives you an option Line Ending and the default is Unix/Linux when I
>>>> hit save there there was no change to what I had previously so I'm pretty
>>>> sure that I'm saving with Unix file endings.
>>>>
>>>> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
>>>> that what you are suggesting would seem about right.
>>>>
>>>> Frase
>>>>
>>>>
>>>> On 10/03/14 17:10, Rob Godfrey wrote:
>>>>
>>>> Is this a function of whichever svn client Jan is using under cygwin
>>>>> assuming that "native" eol-style[1] for that platform is CRLF rather
>>>>> than
>>>>> LF.
>>>>>
>>>>> Given the files wouldn't normally work under windows except under Cygwin
>>>>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
>>>>> native as they are currently)?
>>>>>
>>>>> -- Rob
>>>>>
>>>>> [1]
>>>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>>>>> file-portability.html#svn.advanced.props.special.eol-style
>>>>>
>>>>>
>>>>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>>>>> wrote:
>>>>>
>>>>> Hi Jan,
>>>>>
>>>>>> I have to say that I don't really understand what you are getting at
>>>>>> with
>>>>>> some of these comments - especially "Is there any reason why you use
>>>>>> Windows line endings?"
>>>>>>
>>>>>> I'm using a Linux box - always have done. I generally use gedit on
>>>>>> Linux
>>>>>> to edit and these scripts are no exception.
>>>>>>
>>>>>>
>>>>>> On 10/03/14 09:31, Jan Bares wrote:
>>>>>>
>>>>>> Hi Fraser,
>>>>>>
>>>>>>> Thank you for the change, it works fine, I just have to convert to
>>>>>>> Unix
>>>>>>> line endings. Yes, the cygpath must be called before you use it. What
>>>>>>> I
>>>>>>> meant was to keep just the Cygwin detection code at the script begin.
>>>>>>> Is
>>>>>>> there any reason why you use Windows line endings? I do not have deep
>>>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support
>>>>>>> inside,
>>>>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>>>>>> There you can also see support for Darwin and os400 embedded.
>>>>>>>
>>>>>>> Thanks you, Jan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>
>>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>>>>> To: users@qpid.apache.org
>>>>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>>>>
>>>>>>>> Hi Jan,
>>>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>>>>>>> check to see if that works and give me a yell. If it works then I'll
>>>>>>>> update the other scripts.
>>>>>>>>
>>>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>>>>
>>>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>>>>
>>>>>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>>>>>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>>>>>>> provides a "patch" to one of the classes on that to enable the
>>>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF
>>>>>>>> (see
>>>>>>>> the README.txt)
>>>>>>>>
>>>>>>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>>>>>>> given that I *think* that I need to add your:
>>>>>>>>
>>>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>>>>
>>>>>>>> After I've set the CLASSPATH.
>>>>>>>>
>>>>>>>> Just in case you are wondering why I didn't just shove the Cygwin
>>>>>>>> block
>>>>>>>> at the start.
>>>>>>>>
>>>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Frase
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> DISCLAIMER
>>>>>>> ________________________________
>>>>>>> WOOD & Company Financial Services, a.s. and its branches
>>>>>>> are
>>>>>>> authorized and regulated by the CNB as Home State regulator and in
>>>>>>> Poland
>>>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>>>>> State
>>>>>>> regulators. For further information about WOOD & Co., its investment
>>>>>>> services, financial instruments and associated risks, safeguard client
>>>>>>> assets (incl. compensation schemes) and contractual relationship
>>>>>>> please
>>>>>>> see
>>>>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>>>>> Corporate Governance.
>>>>>>> Unless otherwise stated, this transmission is neither an
>>>>>>> offer
>>>>>>> nor the solicitation of an offer to sell or purchase any investment.
>>>>>>> All
>>>>>>> estimates, opinions and other information contained herein are subject
>>>>>>> to
>>>>>>> change without notice and are provided in good faith but without legal
>>>>>>> responsibility or liability. Opinion may be personal to the author and
>>>>>>> may
>>>>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>>>>> persons,
>>>>>>> sales traders or traders should not be regarded as investment research
>>>>>>> and
>>>>>>> may contain opinions or trading ideas which are different from WOOD &
>>>>>>> Co.
>>>>>>> investment research opinions.
>>>>>>> This e-mail and any attachments are confidential and may
>>>>>>> be
>>>>>>> privileged or otherwise protected from disclosure. If you are not a
>>>>>>> named
>>>>>>> addressee you must not use, disclose, distribute, copy, print or rely
>>>>>>> on
>>>>>>> this e-mail and any of its attachments. Please notify the sender that
>>>>>>> you
>>>>>>> have received this email by mistake by replying to the email, and then
>>>>>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>>>>>> screens e-mails for viruses, addressees should scan this e-mail and
>>>>>>> any
>>>>>>> attachments for viruses. WOOD & Co. makes no representation or
>>>>>>> warranty
>>>>>>> as
>>>>>>> to the absence of viruses in this e-mail or any attachments. Please
>>>>>>> note
>>>>>>> that to ensure regulatory compliance and for the protection of our
>>>>>>> clients
>>>>>>> and business, we may monitor and read e-mails sent to and from our
>>>>>>> server(s).
>>>>>>> ________________________________
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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: QPID C++ broker monitoring and management
Posted by Robbie Gemmell <ro...@gmail.com>.
Read the link Rob sent and all should be clear.
Robbie
On 10 March 2014 18:01, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> You've just confused me now Rob.
> From what I can tell I've saved these files with UNIX style "\n" (0x0A)
> line endings and I'm using the standard Linux svn client so I doubt that's
> nobbling them into Windows style.
>
> I thought that your earlier mail was suggesting that Jan might have been
> using the Windows svn client and it was likely that which is converting the
> end of lines.
>
> So I'm not really sure what you are saying TBH
> Frase
>
>
>
> On 10/03/14 17:39, Rob Godfrey wrote:
>
>> Given that these are .sh files, I think it reasonable for us to change
>> them
>> to have LF eol-style in subversion... I'd imagine anything that ran on
>> windows that emulated a UNIX shell would handle files UNIX style line
>> endings, and it would make life easier for people using Cygwin by the
>> sounds of things.
>>
>> -- Rob
>>
>>
>> On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>> Thanks Rob, that would be my guess too. I've just checked on gedit and if
>>> you do
>>> file->save as
>>>
>>> It gives you an option Line Ending and the default is Unix/Linux when I
>>> hit save there there was no change to what I had previously so I'm pretty
>>> sure that I'm saving with Unix file endings.
>>>
>>> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
>>> that what you are suggesting would seem about right.
>>>
>>> Frase
>>>
>>>
>>> On 10/03/14 17:10, Rob Godfrey wrote:
>>>
>>> Is this a function of whichever svn client Jan is using under cygwin
>>>> assuming that "native" eol-style[1] for that platform is CRLF rather
>>>> than
>>>> LF.
>>>>
>>>> Given the files wouldn't normally work under windows except under Cygwin
>>>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
>>>> native as they are currently)?
>>>>
>>>> -- Rob
>>>>
>>>> [1]
>>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>>>> file-portability.html#svn.advanced.props.special.eol-style
>>>>
>>>>
>>>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>>>> wrote:
>>>>
>>>> Hi Jan,
>>>>
>>>>> I have to say that I don't really understand what you are getting at
>>>>> with
>>>>> some of these comments - especially "Is there any reason why you use
>>>>> Windows line endings?"
>>>>>
>>>>> I'm using a Linux box - always have done. I generally use gedit on
>>>>> Linux
>>>>> to edit and these scripts are no exception.
>>>>>
>>>>>
>>>>> On 10/03/14 09:31, Jan Bares wrote:
>>>>>
>>>>> Hi Fraser,
>>>>>
>>>>>> Thank you for the change, it works fine, I just have to convert to
>>>>>> Unix
>>>>>> line endings. Yes, the cygpath must be called before you use it. What
>>>>>> I
>>>>>> meant was to keep just the Cygwin detection code at the script begin.
>>>>>> Is
>>>>>> there any reason why you use Windows line endings? I do not have deep
>>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support
>>>>>> inside,
>>>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>>>>> There you can also see support for Darwin and os400 embedded.
>>>>>>
>>>>>> Thanks you, Jan
>>>>>>
>>>>>> -----Original Message-----
>>>>>>
>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>>>> To: users@qpid.apache.org
>>>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>>>
>>>>>>> Hi Jan,
>>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>>>>>> check to see if that works and give me a yell. If it works then I'll
>>>>>>> update the other scripts.
>>>>>>>
>>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>>>
>>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>>>
>>>>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>>>>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>>>>>> provides a "patch" to one of the classes on that to enable the
>>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF
>>>>>>> (see
>>>>>>> the README.txt)
>>>>>>>
>>>>>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>>>>>> given that I *think* that I need to add your:
>>>>>>>
>>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>>>
>>>>>>> After I've set the CLASSPATH.
>>>>>>>
>>>>>>> Just in case you are wondering why I didn't just shove the Cygwin
>>>>>>> block
>>>>>>> at the start.
>>>>>>>
>>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Frase
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> DISCLAIMER
>>>>>> ________________________________
>>>>>> WOOD & Company Financial Services, a.s. and its branches
>>>>>> are
>>>>>> authorized and regulated by the CNB as Home State regulator and in
>>>>>> Poland
>>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>>>> State
>>>>>> regulators. For further information about WOOD & Co., its investment
>>>>>> services, financial instruments and associated risks, safeguard client
>>>>>> assets (incl. compensation schemes) and contractual relationship
>>>>>> please
>>>>>> see
>>>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>>>> Corporate Governance.
>>>>>> Unless otherwise stated, this transmission is neither an
>>>>>> offer
>>>>>> nor the solicitation of an offer to sell or purchase any investment.
>>>>>> All
>>>>>> estimates, opinions and other information contained herein are subject
>>>>>> to
>>>>>> change without notice and are provided in good faith but without legal
>>>>>> responsibility or liability. Opinion may be personal to the author and
>>>>>> may
>>>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>>>> persons,
>>>>>> sales traders or traders should not be regarded as investment research
>>>>>> and
>>>>>> may contain opinions or trading ideas which are different from WOOD &
>>>>>> Co.
>>>>>> investment research opinions.
>>>>>> This e-mail and any attachments are confidential and may
>>>>>> be
>>>>>> privileged or otherwise protected from disclosure. If you are not a
>>>>>> named
>>>>>> addressee you must not use, disclose, distribute, copy, print or rely
>>>>>> on
>>>>>> this e-mail and any of its attachments. Please notify the sender that
>>>>>> you
>>>>>> have received this email by mistake by replying to the email, and then
>>>>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>>>>> screens e-mails for viruses, addressees should scan this e-mail and
>>>>>> any
>>>>>> attachments for viruses. WOOD & Co. makes no representation or
>>>>>> warranty
>>>>>> as
>>>>>> to the absence of viruses in this e-mail or any attachments. Please
>>>>>> note
>>>>>> that to ensure regulatory compliance and for the protection of our
>>>>>> clients
>>>>>> and business, we may monitor and read e-mails sent to and from our
>>>>>> server(s).
>>>>>> ________________________________
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
You've just confused me now Rob.
From what I can tell I've saved these files with UNIX style "\n" (0x0A)
line endings and I'm using the standard Linux svn client so I doubt
that's nobbling them into Windows style.
I thought that your earlier mail was suggesting that Jan might have been
using the Windows svn client and it was likely that which is converting
the end of lines.
So I'm not really sure what you are saying TBH
Frase
On 10/03/14 17:39, Rob Godfrey wrote:
> Given that these are .sh files, I think it reasonable for us to change them
> to have LF eol-style in subversion... I'd imagine anything that ran on
> windows that emulated a UNIX shell would handle files UNIX style line
> endings, and it would make life easier for people using Cygwin by the
> sounds of things.
>
> -- Rob
>
>
> On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> Thanks Rob, that would be my guess too. I've just checked on gedit and if
>> you do
>> file->save as
>>
>> It gives you an option Line Ending and the default is Unix/Linux when I
>> hit save there there was no change to what I had previously so I'm pretty
>> sure that I'm saving with Unix file endings.
>>
>> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
>> that what you are suggesting would seem about right.
>>
>> Frase
>>
>>
>> On 10/03/14 17:10, Rob Godfrey wrote:
>>
>>> Is this a function of whichever svn client Jan is using under cygwin
>>> assuming that "native" eol-style[1] for that platform is CRLF rather than
>>> LF.
>>>
>>> Given the files wouldn't normally work under windows except under Cygwin
>>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
>>> native as they are currently)?
>>>
>>> -- Rob
>>>
>>> [1]
>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>>> file-portability.html#svn.advanced.props.special.eol-style
>>>
>>>
>>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>> Hi Jan,
>>>> I have to say that I don't really understand what you are getting at with
>>>> some of these comments - especially "Is there any reason why you use
>>>> Windows line endings?"
>>>>
>>>> I'm using a Linux box - always have done. I generally use gedit on Linux
>>>> to edit and these scripts are no exception.
>>>>
>>>>
>>>> On 10/03/14 09:31, Jan Bares wrote:
>>>>
>>>> Hi Fraser,
>>>>> Thank you for the change, it works fine, I just have to convert to Unix
>>>>> line endings. Yes, the cygpath must be called before you use it. What I
>>>>> meant was to keep just the Cygwin detection code at the script begin. Is
>>>>> there any reason why you use Windows line endings? I do not have deep
>>>>> Cygwin knowledge, but all shell scripts that have Cygwin support inside,
>>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>>>> There you can also see support for Darwin and os400 embedded.
>>>>>
>>>>> Thanks you, Jan
>>>>>
>>>>> -----Original Message-----
>>>>>
>>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>>> To: users@qpid.apache.org
>>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>>
>>>>>> Hi Jan,
>>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>>>>> check to see if that works and give me a yell. If it works then I'll
>>>>>> update the other scripts.
>>>>>>
>>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>>
>>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>>
>>>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>>>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>>>>> provides a "patch" to one of the classes on that to enable the
>>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
>>>>>> the README.txt)
>>>>>>
>>>>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>>>>> given that I *think* that I need to add your:
>>>>>>
>>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>>
>>>>>> After I've set the CLASSPATH.
>>>>>>
>>>>>> Just in case you are wondering why I didn't just shove the Cygwin block
>>>>>> at the start.
>>>>>>
>>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>>
>>>>>> Regards,
>>>>>> Frase
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> DISCLAIMER
>>>>> ________________________________
>>>>> WOOD & Company Financial Services, a.s. and its branches are
>>>>> authorized and regulated by the CNB as Home State regulator and in
>>>>> Poland
>>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>>> State
>>>>> regulators. For further information about WOOD & Co., its investment
>>>>> services, financial instruments and associated risks, safeguard client
>>>>> assets (incl. compensation schemes) and contractual relationship please
>>>>> see
>>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>>> Corporate Governance.
>>>>> Unless otherwise stated, this transmission is neither an
>>>>> offer
>>>>> nor the solicitation of an offer to sell or purchase any investment. All
>>>>> estimates, opinions and other information contained herein are subject
>>>>> to
>>>>> change without notice and are provided in good faith but without legal
>>>>> responsibility or liability. Opinion may be personal to the author and
>>>>> may
>>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>>> persons,
>>>>> sales traders or traders should not be regarded as investment research
>>>>> and
>>>>> may contain opinions or trading ideas which are different from WOOD &
>>>>> Co.
>>>>> investment research opinions.
>>>>> This e-mail and any attachments are confidential and may be
>>>>> privileged or otherwise protected from disclosure. If you are not a
>>>>> named
>>>>> addressee you must not use, disclose, distribute, copy, print or rely on
>>>>> this e-mail and any of its attachments. Please notify the sender that
>>>>> you
>>>>> have received this email by mistake by replying to the email, and then
>>>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>>>> screens e-mails for viruses, addressees should scan this e-mail and any
>>>>> attachments for viruses. WOOD & Co. makes no representation or warranty
>>>>> as
>>>>> to the absence of viruses in this e-mail or any attachments. Please note
>>>>> that to ensure regulatory compliance and for the protection of our
>>>>> clients
>>>>> and business, we may monitor and read e-mails sent to and from our
>>>>> server(s).
>>>>> ________________________________
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: QPID C++ broker monitoring and management
Posted by Rob Godfrey <ro...@gmail.com>.
Given that these are .sh files, I think it reasonable for us to change them
to have LF eol-style in subversion... I'd imagine anything that ran on
windows that emulated a UNIX shell would handle files UNIX style line
endings, and it would make life easier for people using Cygwin by the
sounds of things.
-- Rob
On 10 March 2014 18:25, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Thanks Rob, that would be my guess too. I've just checked on gedit and if
> you do
> file->save as
>
> It gives you an option Line Ending and the default is Unix/Linux when I
> hit save there there was no change to what I had previously so I'm pretty
> sure that I'm saving with Unix file endings.
>
> Just checked with a hex editor too and I'm just seeing 0x0A, so I think
> that what you are suggesting would seem about right.
>
> Frase
>
>
> On 10/03/14 17:10, Rob Godfrey wrote:
>
>> Is this a function of whichever svn client Jan is using under cygwin
>> assuming that "native" eol-style[1] for that platform is CRLF rather than
>> LF.
>>
>> Given the files wouldn't normally work under windows except under Cygwin
>> perhaps changing the svn:eol-style of the .sh files to LF (rather than
>> native as they are currently)?
>>
>> -- Rob
>>
>> [1]
>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.
>> file-portability.html#svn.advanced.props.special.eol-style
>>
>>
>> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>> Hi Jan,
>>> I have to say that I don't really understand what you are getting at with
>>> some of these comments - especially "Is there any reason why you use
>>> Windows line endings?"
>>>
>>> I'm using a Linux box - always have done. I generally use gedit on Linux
>>> to edit and these scripts are no exception.
>>>
>>>
>>> On 10/03/14 09:31, Jan Bares wrote:
>>>
>>> Hi Fraser,
>>>>
>>>> Thank you for the change, it works fine, I just have to convert to Unix
>>>> line endings. Yes, the cygpath must be called before you use it. What I
>>>> meant was to keep just the Cygwin detection code at the script begin. Is
>>>> there any reason why you use Windows line endings? I do not have deep
>>>> Cygwin knowledge, but all shell scripts that have Cygwin support inside,
>>>> such as Tomcat catalina.sh, use Unix line endings. See
>>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>>> There you can also see support for Darwin and os400 embedded.
>>>>
>>>> Thanks you, Jan
>>>>
>>>> -----Original Message-----
>>>>
>>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>>> To: users@qpid.apache.org
>>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>>
>>>>> Hi Jan,
>>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>>>> check to see if that works and give me a yell. If it works then I'll
>>>>> update the other scripts.
>>>>>
>>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>>
>>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>>
>>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>>>> provides a "patch" to one of the classes on that to enable the
>>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
>>>>> the README.txt)
>>>>>
>>>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>>>> given that I *think* that I need to add your:
>>>>>
>>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>>
>>>>> After I've set the CLASSPATH.
>>>>>
>>>>> Just in case you are wondering why I didn't just shove the Cygwin block
>>>>> at the start.
>>>>>
>>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>>
>>>>> Regards,
>>>>> Frase
>>>>>
>>>>>
>>>>>
>>>>>
>>>> DISCLAIMER
>>>> ________________________________
>>>> WOOD & Company Financial Services, a.s. and its branches are
>>>> authorized and regulated by the CNB as Home State regulator and in
>>>> Poland
>>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
>>>> State
>>>> regulators. For further information about WOOD & Co., its investment
>>>> services, financial instruments and associated risks, safeguard client
>>>> assets (incl. compensation schemes) and contractual relationship please
>>>> see
>>>> our website at www.wood.com<http://www.wood.com/> under section
>>>> Corporate Governance.
>>>> Unless otherwise stated, this transmission is neither an
>>>> offer
>>>> nor the solicitation of an offer to sell or purchase any investment. All
>>>> estimates, opinions and other information contained herein are subject
>>>> to
>>>> change without notice and are provided in good faith but without legal
>>>> responsibility or liability. Opinion may be personal to the author and
>>>> may
>>>> not reflect the opinions of WOOD & Co. Communications from sales
>>>> persons,
>>>> sales traders or traders should not be regarded as investment research
>>>> and
>>>> may contain opinions or trading ideas which are different from WOOD &
>>>> Co.
>>>> investment research opinions.
>>>> This e-mail and any attachments are confidential and may be
>>>> privileged or otherwise protected from disclosure. If you are not a
>>>> named
>>>> addressee you must not use, disclose, distribute, copy, print or rely on
>>>> this e-mail and any of its attachments. Please notify the sender that
>>>> you
>>>> have received this email by mistake by replying to the email, and then
>>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>>> screens e-mails for viruses, addressees should scan this e-mail and any
>>>> attachments for viruses. WOOD & Co. makes no representation or warranty
>>>> as
>>>> to the absence of viruses in this e-mail or any attachments. Please note
>>>> that to ensure regulatory compliance and for the protection of our
>>>> clients
>>>> and business, we may monitor and read e-mails sent to and from our
>>>> server(s).
>>>> ________________________________
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Thanks Rob, that would be my guess too. I've just checked on gedit and
if you do
file->save as
It gives you an option Line Ending and the default is Unix/Linux when I
hit save there there was no change to what I had previously so I'm
pretty sure that I'm saving with Unix file endings.
Just checked with a hex editor too and I'm just seeing 0x0A, so I think
that what you are suggesting would seem about right.
Frase
On 10/03/14 17:10, Rob Godfrey wrote:
> Is this a function of whichever svn client Jan is using under cygwin
> assuming that "native" eol-style[1] for that platform is CRLF rather than
> LF.
>
> Given the files wouldn't normally work under windows except under Cygwin
> perhaps changing the svn:eol-style of the .sh files to LF (rather than
> native as they are currently)?
>
> -- Rob
>
> [1]
> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
>
>
> On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>> Hi Jan,
>> I have to say that I don't really understand what you are getting at with
>> some of these comments - especially "Is there any reason why you use
>> Windows line endings?"
>>
>> I'm using a Linux box - always have done. I generally use gedit on Linux
>> to edit and these scripts are no exception.
>>
>>
>> On 10/03/14 09:31, Jan Bares wrote:
>>
>>> Hi Fraser,
>>>
>>> Thank you for the change, it works fine, I just have to convert to Unix
>>> line endings. Yes, the cygpath must be called before you use it. What I
>>> meant was to keep just the Cygwin detection code at the script begin. Is
>>> there any reason why you use Windows line endings? I do not have deep
>>> Cygwin knowledge, but all shell scripts that have Cygwin support inside,
>>> such as Tomcat catalina.sh, use Unix line endings. See
>>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>>> There you can also see support for Darwin and os400 embedded.
>>>
>>> Thanks you, Jan
>>>
>>> -----Original Message-----
>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>> Sent: Saturday, March 08, 2014 2:12 PM
>>>> To: users@qpid.apache.org
>>>> Subject: Re: QPID C++ broker monitoring and management
>>>>
>>>> Hi Jan,
>>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>>> check to see if that works and give me a yell. If it works then I'll
>>>> update the other scripts.
>>>>
>>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>>
>>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>>
>>>> myself because the qpid-client-patch.jar gets put *before* the main
>>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>>> provides a "patch" to one of the classes on that to enable the
>>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
>>>> the README.txt)
>>>>
>>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>>> given that I *think* that I need to add your:
>>>>
>>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>>
>>>> After I've set the CLASSPATH.
>>>>
>>>> Just in case you are wondering why I didn't just shove the Cygwin block
>>>> at the start.
>>>>
>>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>>
>>>> Regards,
>>>> Frase
>>>>
>>>>
>>>>
>>>
>>> DISCLAIMER
>>> ________________________________
>>> WOOD & Company Financial Services, a.s. and its branches are
>>> authorized and regulated by the CNB as Home State regulator and in Poland
>>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State
>>> regulators. For further information about WOOD & Co., its investment
>>> services, financial instruments and associated risks, safeguard client
>>> assets (incl. compensation schemes) and contractual relationship please see
>>> our website at www.wood.com<http://www.wood.com/> under section
>>> Corporate Governance.
>>> Unless otherwise stated, this transmission is neither an offer
>>> nor the solicitation of an offer to sell or purchase any investment. All
>>> estimates, opinions and other information contained herein are subject to
>>> change without notice and are provided in good faith but without legal
>>> responsibility or liability. Opinion may be personal to the author and may
>>> not reflect the opinions of WOOD & Co. Communications from sales persons,
>>> sales traders or traders should not be regarded as investment research and
>>> may contain opinions or trading ideas which are different from WOOD & Co.
>>> investment research opinions.
>>> This e-mail and any attachments are confidential and may be
>>> privileged or otherwise protected from disclosure. If you are not a named
>>> addressee you must not use, disclose, distribute, copy, print or rely on
>>> this e-mail and any of its attachments. Please notify the sender that you
>>> have received this email by mistake by replying to the email, and then
>>> delete the email and any copies of it. Although WOOD & Co. routinely
>>> screens e-mails for viruses, addressees should scan this e-mail and any
>>> attachments for viruses. WOOD & Co. makes no representation or warranty as
>>> to the absence of viruses in this e-mail or any attachments. Please note
>>> that to ensure regulatory compliance and for the protection of our clients
>>> and business, we may monitor and read e-mails sent to and from our
>>> server(s).
>>> ________________________________
>>>
>>> ---------------------------------------------------------------------
>>> 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: QPID C++ broker monitoring and management
Posted by Rob Godfrey <ro...@gmail.com>.
Is this a function of whichever svn client Jan is using under cygwin
assuming that "native" eol-style[1] for that platform is CRLF rather than
LF.
Given the files wouldn't normally work under windows except under Cygwin
perhaps changing the svn:eol-style of the .sh files to LF (rather than
native as they are currently)?
-- Rob
[1]
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
On 10 March 2014 18:00, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi Jan,
> I have to say that I don't really understand what you are getting at with
> some of these comments - especially "Is there any reason why you use
> Windows line endings?"
>
> I'm using a Linux box - always have done. I generally use gedit on Linux
> to edit and these scripts are no exception.
>
>
> On 10/03/14 09:31, Jan Bares wrote:
>
>> Hi Fraser,
>>
>> Thank you for the change, it works fine, I just have to convert to Unix
>> line endings. Yes, the cygpath must be called before you use it. What I
>> meant was to keep just the Cygwin detection code at the script begin. Is
>> there any reason why you use Windows line endings? I do not have deep
>> Cygwin knowledge, but all shell scripts that have Cygwin support inside,
>> such as Tomcat catalina.sh, use Unix line endings. See
>> http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log.
>> There you can also see support for Darwin and os400 embedded.
>>
>> Thanks you, Jan
>>
>> -----Original Message-----
>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>> Sent: Saturday, March 08, 2014 2:12 PM
>>> To: users@qpid.apache.org
>>> Subject: Re: QPID C++ broker monitoring and management
>>>
>>> Hi Jan,
>>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>>> check to see if that works and give me a yell. If it works then I'll
>>> update the other scripts.
>>>
>>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>>
>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>>
>>> myself because the qpid-client-patch.jar gets put *before* the main
>>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>>> but that patch is an optional thing for people running < Qpid 0.12 it
>>> provides a "patch" to one of the classes on that to enable the
>>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
>>> the README.txt)
>>>
>>> Hopefully nobody is using that stuff now, but you never know :-) but
>>> given that I *think* that I need to add your:
>>>
>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>>
>>> After I've set the CLASSPATH.
>>>
>>> Just in case you are wondering why I didn't just shove the Cygwin block
>>> at the start.
>>>
>>> Let me know if it works and I'll fix the other scripts ASAP.
>>>
>>> Regards,
>>> Frase
>>>
>>>
>>>
>>
>>
>> DISCLAIMER
>> ________________________________
>> WOOD & Company Financial Services, a.s. and its branches are
>> authorized and regulated by the CNB as Home State regulator and in Poland
>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State
>> regulators. For further information about WOOD & Co., its investment
>> services, financial instruments and associated risks, safeguard client
>> assets (incl. compensation schemes) and contractual relationship please see
>> our website at www.wood.com<http://www.wood.com/> under section
>> Corporate Governance.
>> Unless otherwise stated, this transmission is neither an offer
>> nor the solicitation of an offer to sell or purchase any investment. All
>> estimates, opinions and other information contained herein are subject to
>> change without notice and are provided in good faith but without legal
>> responsibility or liability. Opinion may be personal to the author and may
>> not reflect the opinions of WOOD & Co. Communications from sales persons,
>> sales traders or traders should not be regarded as investment research and
>> may contain opinions or trading ideas which are different from WOOD & Co.
>> investment research opinions.
>> This e-mail and any attachments are confidential and may be
>> privileged or otherwise protected from disclosure. If you are not a named
>> addressee you must not use, disclose, distribute, copy, print or rely on
>> this e-mail and any of its attachments. Please notify the sender that you
>> have received this email by mistake by replying to the email, and then
>> delete the email and any copies of it. Although WOOD & Co. routinely
>> screens e-mails for viruses, addressees should scan this e-mail and any
>> attachments for viruses. WOOD & Co. makes no representation or warranty as
>> to the absence of viruses in this e-mail or any attachments. Please note
>> that to ensure regulatory compliance and for the protection of our clients
>> and business, we may monitor and read e-mails sent to and from our
>> server(s).
>> ________________________________
>>
>> ---------------------------------------------------------------------
>> 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: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
I have to say that I don't really understand what you are getting at
with some of these comments - especially "Is there any reason why you
use Windows line endings?"
I'm using a Linux box - always have done. I generally use gedit on Linux
to edit and these scripts are no exception.
On 10/03/14 09:31, Jan Bares wrote:
> Hi Fraser,
>
> Thank you for the change, it works fine, I just have to convert to Unix line endings. Yes, the cygpath must be called before you use it. What I meant was to keep just the Cygwin detection code at the script begin. Is there any reason why you use Windows line endings? I do not have deep Cygwin knowledge, but all shell scripts that have Cygwin support inside, such as Tomcat catalina.sh, use Unix line endings. See http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log. There you can also see support for Darwin and os400 embedded.
>
> Thanks you, Jan
>
>> -----Original Message-----
>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>> Sent: Saturday, March 08, 2014 2:12 PM
>> To: users@qpid.apache.org
>> Subject: Re: QPID C++ broker monitoring and management
>>
>> Hi Jan,
>> I've committed an update to QpidRestAPI.sh on trunk. Could you please
>> check to see if that works and give me a yell. If it works then I'll
>> update the other scripts.
>>
>> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>>
>> CLASSPATH=$QMF2_LIBS/qpid-client-
>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>>
>> myself because the qpid-client-patch.jar gets put *before* the main
>> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
>> but that patch is an optional thing for people running < Qpid 0.12 it
>> provides a "patch" to one of the classes on that to enable the
>> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
>> the README.txt)
>>
>> Hopefully nobody is using that stuff now, but you never know :-) but
>> given that I *think* that I need to add your:
>>
>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>
>> After I've set the CLASSPATH.
>>
>> Just in case you are wondering why I didn't just shove the Cygwin block
>> at the start.
>>
>> Let me know if it works and I'll fix the other scripts ASAP.
>>
>> Regards,
>> Frase
>>
>>
>
>
>
> DISCLAIMER
> ________________________________
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
Hi Fraser,
Thank you for the change, it works fine, I just have to convert to Unix line endings. Yes, the cygpath must be called before you use it. What I meant was to keep just the Cygwin detection code at the script begin. Is there any reason why you use Windows line endings? I do not have deep Cygwin knowledge, but all shell scripts that have Cygwin support inside, such as Tomcat catalina.sh, use Unix line endings. See http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?view=log. There you can also see support for Darwin and os400 embedded.
Thanks you, Jan
> -----Original Message-----
> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> Sent: Saturday, March 08, 2014 2:12 PM
> To: users@qpid.apache.org
> Subject: Re: QPID C++ broker monitoring and management
>
> Hi Jan,
> I've committed an update to QpidRestAPI.sh on trunk. Could you please
> check to see if that works and give me a yell. If it works then I'll
> update the other scripts.
>
> BTW I've added the Cygwin stuff *after* I set CLASSPATH to
>
> CLASSPATH=$QMF2_LIBS/qpid-client-
> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
>
> myself because the qpid-client-patch.jar gets put *before* the main
> CLASSPATH (which would have the qpid jars on it). That's a bit quirky
> but that patch is an optional thing for people running < Qpid 0.12 it
> provides a "patch" to one of the classes on that to enable the
> "x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
> the README.txt)
>
> Hopefully nobody is using that stuff now, but you never know :-) but
> given that I *think* that I need to add your:
>
> CLASSPATH=$(cygpath -wp $CLASSPATH)
>
> After I've set the CLASSPATH.
>
> Just in case you are wondering why I didn't just shove the Cygwin block
> at the start.
>
> Let me know if it works and I'll fix the other scripts ASAP.
>
> Regards,
> Frase
>
>
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
I've committed an update to QpidRestAPI.sh on trunk. Could you please
check to see if that works and give me a yell. If it works then I'll
update the other scripts.
BTW I've added the Cygwin stuff *after* I set CLASSPATH to
CLASSPATH=$QMF2_LIBS/qpid-client-patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar:$QMF2_LIBS/restapi.jar
myself because the qpid-client-patch.jar gets put *before* the main
CLASSPATH (which would have the qpid jars on it). That's a bit quirky
but that patch is an optional thing for people running < Qpid 0.12 it
provides a "patch" to one of the classes on that to enable the
"x-amqp-0-10.app-id" property to be added, which is needed for QMF (see
the README.txt)
Hopefully nobody is using that stuff now, but you never know :-) but
given that I *think* that I need to add your:
CLASSPATH=$(cygpath -wp $CLASSPATH)
After I've set the CLASSPATH.
Just in case you are wondering why I didn't just shove the Cygwin block
at the start.
Let me know if it works and I'll fix the other scripts ASAP.
Regards,
Frase
On 06/03/14 07:27, Jan Bares wrote:
> Hi,
>
> See inline
>
>> Hi Jan,
>> Just looked through your Jira. I'm not familiar with Cygwin I'm afraid -
>> I tend to do all my stuff on a Linux box, are you saying that all I need
>> to do is something like (not sure the best place to put your tweak
>> without trying it):
>>
>>
>> WHEREAMI=`dirname $0`
>> if [ -z "$QMF2_HOME" ]; then
>> export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
>> fi
>>
>> QMF2_LIBS=$QMF2_HOME/build/lib
>>
>> CLASSPATH=$QMF2_LIBS/qpid-client-
>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
>>
>> # Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
>> if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
>> PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
>> fi
>>
>> cygwin=false;
>> case "`uname`" in
>> CYGWIN*) cygwin=true;;
>> esac
> Standard way to check if running of Cygwin, the uname returns something like: CYGWIN_NT-6.1-WOW64
>
> I suggest to place this check to the script begin.
>
>> if $cygwin; then
>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>> fi
> On Cygwin full paths begin with cygdrive and drive name, e.g. "/cygdrive/c/Programs.Java/RedHat/qpid". Windows programs doesn't understand it, cygpath converts the path to windows path including conversion of ":" to ";"
>
>>
>> java -cp $CLASSPATH $PROPERTIES
>> org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
> It works for me, if it works for you too, this will help a lot. I am on trunk, I can check immediately.
>
> Thanks, Jan
>
>
>
>
> DISCLAIMER
> ________________________________
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Robbie Gemmell <ro...@gmail.com>.
We will do exactly that as part of
https://issues.apache.org/jira/browse/QPID-5610
Robbie
On 7 March 2014 11:38, Rob Godfrey <ro...@gmail.com> 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
>
>
> On 7 March 2014 10:27, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
> > Hi Jan,
> > for info I was planning on taking a look at this just now, but I've just
> > done an svn update and unfortunately there have been a number of changes
> to
> > the Java Broker Management API that have caused the QMF plugin to break
> > badly. I'll get the Cygwin tweaks done when I manage to fix what's been
> > broken.
> >
> > To be clear the main QMF API and GUI still work for the C++ broker (if
> you
> > do just "ant") but if you do "ant all" to try to build the Java Broker
> > plugin it's looking a bit sad at the moment :-(
> >
> > I'll get back to you when I get things working again - sorry!
> > Frase
> >
> >
> >
> > On 06/03/14 07:27, Jan Bares wrote:
> >
> >> Hi,
> >>
> >> See inline
> >>
> >> Hi Jan,
> >>> Just looked through your Jira. I'm not familiar with Cygwin I'm afraid
> -
> >>> I tend to do all my stuff on a Linux box, are you saying that all I
> need
> >>> to do is something like (not sure the best place to put your tweak
> >>> without trying it):
> >>>
> >>>
> >>> WHEREAMI=`dirname $0`
> >>> if [ -z "$QMF2_HOME" ]; then
> >>> export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
> >>> fi
> >>>
> >>> QMF2_LIBS=$QMF2_HOME/build/lib
> >>>
> >>> CLASSPATH=$QMF2_LIBS/qpid-client-
> >>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
> >>>
> >>> # Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
> >>> if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
> >>> PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
> >>> fi
> >>>
> >>> cygwin=false;
> >>> case "`uname`" in
> >>> CYGWIN*) cygwin=true;;
> >>> esac
> >>>
> >> Standard way to check if running of Cygwin, the uname returns something
> >> like: CYGWIN_NT-6.1-WOW64
> >>
> >> I suggest to place this check to the script begin.
> >>
> >> if $cygwin; then
> >>> CLASSPATH=$(cygpath -wp $CLASSPATH)
> >>> fi
> >>>
> >> On Cygwin full paths begin with cygdrive and drive name, e.g.
> >> "/cygdrive/c/Programs.Java/RedHat/qpid". Windows programs doesn't
> >> understand it, cygpath converts the path to windows path including
> >> conversion of ":" to ";"
> >>
> >>
> >>> java -cp $CLASSPATH $PROPERTIES
> >>> org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
> >>>
> >> It works for me, if it works for you too, this will help a lot. I am on
> >> trunk, I can check immediately.
> >>
> >> Thanks, Jan
> >>
> >>
> >>
> >>
> >> DISCLAIMER
> >> ________________________________
> >> WOOD & Company Financial Services, a.s. and its branches are
> >> authorized and regulated by the CNB as Home State regulator and in
> Poland
> >> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host
> State
> >> regulators. For further information about WOOD & Co., its investment
> >> services, financial instruments and associated risks, safeguard client
> >> assets (incl. compensation schemes) and contractual relationship please
> see
> >> our website at www.wood.com<http://www.wood.com/> under section
> >> Corporate Governance.
> >> Unless otherwise stated, this transmission is neither an offer
> >> nor the solicitation of an offer to sell or purchase any investment. All
> >> estimates, opinions and other information contained herein are subject
> to
> >> change without notice and are provided in good faith but without legal
> >> responsibility or liability. Opinion may be personal to the author and
> may
> >> not reflect the opinions of WOOD & Co. Communications from sales
> persons,
> >> sales traders or traders should not be regarded as investment research
> and
> >> may contain opinions or trading ideas which are different from WOOD &
> Co.
> >> investment research opinions.
> >> This e-mail and any attachments are confidential and may be
> >> privileged or otherwise protected from disclosure. If you are not a
> named
> >> addressee you must not use, disclose, distribute, copy, print or rely on
> >> this e-mail and any of its attachments. Please notify the sender that
> you
> >> have received this email by mistake by replying to the email, and then
> >> delete the email and any copies of it. Although WOOD & Co. routinely
> >> screens e-mails for viruses, addressees should scan this e-mail and any
> >> attachments for viruses. WOOD & Co. makes no representation or warranty
> as
> >> to the absence of viruses in this e-mail or any attachments. Please note
> >> that to ensure regulatory compliance and for the protection of our
> clients
> >> and business, we may monitor and read e-mails sent to and from our
> >> server(s).
> >> ________________________________
> >>
> >> ---------------------------------------------------------------------
> >> 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
>
>
Java Broker plugin change - was Re: QPID C++ broker monitoring and
management
Posted by 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: QPID C++ broker monitoring and management
Posted by Rob Godfrey <ro...@gmail.com>.
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
On 7 March 2014 10:27, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi Jan,
> for info I was planning on taking a look at this just now, but I've just
> done an svn update and unfortunately there have been a number of changes to
> the Java Broker Management API that have caused the QMF plugin to break
> badly. I'll get the Cygwin tweaks done when I manage to fix what's been
> broken.
>
> To be clear the main QMF API and GUI still work for the C++ broker (if you
> do just "ant") but if you do "ant all" to try to build the Java Broker
> plugin it's looking a bit sad at the moment :-(
>
> I'll get back to you when I get things working again - sorry!
> Frase
>
>
>
> On 06/03/14 07:27, Jan Bares wrote:
>
>> Hi,
>>
>> See inline
>>
>> Hi Jan,
>>> Just looked through your Jira. I'm not familiar with Cygwin I'm afraid -
>>> I tend to do all my stuff on a Linux box, are you saying that all I need
>>> to do is something like (not sure the best place to put your tweak
>>> without trying it):
>>>
>>>
>>> WHEREAMI=`dirname $0`
>>> if [ -z "$QMF2_HOME" ]; then
>>> export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
>>> fi
>>>
>>> QMF2_LIBS=$QMF2_HOME/build/lib
>>>
>>> CLASSPATH=$QMF2_LIBS/qpid-client-
>>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
>>>
>>> # Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
>>> if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
>>> PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
>>> fi
>>>
>>> cygwin=false;
>>> case "`uname`" in
>>> CYGWIN*) cygwin=true;;
>>> esac
>>>
>> Standard way to check if running of Cygwin, the uname returns something
>> like: CYGWIN_NT-6.1-WOW64
>>
>> I suggest to place this check to the script begin.
>>
>> if $cygwin; then
>>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>>> fi
>>>
>> On Cygwin full paths begin with cygdrive and drive name, e.g.
>> "/cygdrive/c/Programs.Java/RedHat/qpid". Windows programs doesn't
>> understand it, cygpath converts the path to windows path including
>> conversion of ":" to ";"
>>
>>
>>> java -cp $CLASSPATH $PROPERTIES
>>> org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
>>>
>> It works for me, if it works for you too, this will help a lot. I am on
>> trunk, I can check immediately.
>>
>> Thanks, Jan
>>
>>
>>
>>
>> DISCLAIMER
>> ________________________________
>> WOOD & Company Financial Services, a.s. and its branches are
>> authorized and regulated by the CNB as Home State regulator and in Poland
>> by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State
>> regulators. For further information about WOOD & Co., its investment
>> services, financial instruments and associated risks, safeguard client
>> assets (incl. compensation schemes) and contractual relationship please see
>> our website at www.wood.com<http://www.wood.com/> under section
>> Corporate Governance.
>> Unless otherwise stated, this transmission is neither an offer
>> nor the solicitation of an offer to sell or purchase any investment. All
>> estimates, opinions and other information contained herein are subject to
>> change without notice and are provided in good faith but without legal
>> responsibility or liability. Opinion may be personal to the author and may
>> not reflect the opinions of WOOD & Co. Communications from sales persons,
>> sales traders or traders should not be regarded as investment research and
>> may contain opinions or trading ideas which are different from WOOD & Co.
>> investment research opinions.
>> This e-mail and any attachments are confidential and may be
>> privileged or otherwise protected from disclosure. If you are not a named
>> addressee you must not use, disclose, distribute, copy, print or rely on
>> this e-mail and any of its attachments. Please notify the sender that you
>> have received this email by mistake by replying to the email, and then
>> delete the email and any copies of it. Although WOOD & Co. routinely
>> screens e-mails for viruses, addressees should scan this e-mail and any
>> attachments for viruses. WOOD & Co. makes no representation or warranty as
>> to the absence of viruses in this e-mail or any attachments. Please note
>> that to ensure regulatory compliance and for the protection of our clients
>> and business, we may monitor and read e-mails sent to and from our
>> server(s).
>> ________________________________
>>
>> ---------------------------------------------------------------------
>> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
No problem at all, I am on C++ broker and QMF GUI is nice gem, I should have look into it sooner. I will also try to use ACLs but right now I am on other tasks too, will let you know.
Kind regards, Jan
> Hi Jan,
> for info I was planning on taking a look at this just now, but I've just
> done an svn update and unfortunately there have been a number of
> changes
> to the Java Broker Management API that have caused the QMF plugin to
> break badly. I'll get the Cygwin tweaks done when I manage to fix what's
> been broken.
>
> To be clear the main QMF API and GUI still work for the C++ broker (if
> you do just "ant") but if you do "ant all" to try to build the Java
> Broker plugin it's looking a bit sad at the moment :-(
>
> I'll get back to you when I get things working again - sorry!
> Frase
>
>
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
for info I was planning on taking a look at this just now, but I've just
done an svn update and unfortunately there have been a number of changes
to the Java Broker Management API that have caused the QMF plugin to
break badly. I'll get the Cygwin tweaks done when I manage to fix what's
been broken.
To be clear the main QMF API and GUI still work for the C++ broker (if
you do just "ant") but if you do "ant all" to try to build the Java
Broker plugin it's looking a bit sad at the moment :-(
I'll get back to you when I get things working again - sorry!
Frase
On 06/03/14 07:27, Jan Bares wrote:
> Hi,
>
> See inline
>
>> Hi Jan,
>> Just looked through your Jira. I'm not familiar with Cygwin I'm afraid -
>> I tend to do all my stuff on a Linux box, are you saying that all I need
>> to do is something like (not sure the best place to put your tweak
>> without trying it):
>>
>>
>> WHEREAMI=`dirname $0`
>> if [ -z "$QMF2_HOME" ]; then
>> export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
>> fi
>>
>> QMF2_LIBS=$QMF2_HOME/build/lib
>>
>> CLASSPATH=$QMF2_LIBS/qpid-client-
>> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
>>
>> # Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
>> if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
>> PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
>> fi
>>
>> cygwin=false;
>> case "`uname`" in
>> CYGWIN*) cygwin=true;;
>> esac
> Standard way to check if running of Cygwin, the uname returns something like: CYGWIN_NT-6.1-WOW64
>
> I suggest to place this check to the script begin.
>
>> if $cygwin; then
>> CLASSPATH=$(cygpath -wp $CLASSPATH)
>> fi
> On Cygwin full paths begin with cygdrive and drive name, e.g. "/cygdrive/c/Programs.Java/RedHat/qpid". Windows programs doesn't understand it, cygpath converts the path to windows path including conversion of ":" to ";"
>
>>
>> java -cp $CLASSPATH $PROPERTIES
>> org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
> It works for me, if it works for you too, this will help a lot. I am on trunk, I can check immediately.
>
> Thanks, Jan
>
>
>
>
> DISCLAIMER
> ________________________________
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
Hi,
See inline
> Hi Jan,
> Just looked through your Jira. I'm not familiar with Cygwin I'm afraid -
> I tend to do all my stuff on a Linux box, are you saying that all I need
> to do is something like (not sure the best place to put your tweak
> without trying it):
>
>
> WHEREAMI=`dirname $0`
> if [ -z "$QMF2_HOME" ]; then
> export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
> fi
>
> QMF2_LIBS=$QMF2_HOME/build/lib
>
> CLASSPATH=$QMF2_LIBS/qpid-client-
> patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
>
> # Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
> if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
> PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
> fi
>
> cygwin=false;
> case "`uname`" in
> CYGWIN*) cygwin=true;;
> esac
Standard way to check if running of Cygwin, the uname returns something like: CYGWIN_NT-6.1-WOW64
I suggest to place this check to the script begin.
>
> if $cygwin; then
> CLASSPATH=$(cygpath -wp $CLASSPATH)
> fi
On Cygwin full paths begin with cygdrive and drive name, e.g. "/cygdrive/c/Programs.Java/RedHat/qpid". Windows programs doesn't understand it, cygpath converts the path to windows path including conversion of ":" to ";"
>
>
> java -cp $CLASSPATH $PROPERTIES
> org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
It works for me, if it works for you too, this will help a lot. I am on trunk, I can check immediately.
Thanks, Jan
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
Just looked through your Jira. I'm not familiar with Cygwin I'm afraid -
I tend to do all my stuff on a Linux box, are you saying that all I need
to do is something like (not sure the best place to put your tweak
without trying it):
WHEREAMI=`dirname $0`
if [ -z "$QMF2_HOME" ]; then
export QMF2_HOME=`cd $WHEREAMI/../ && pwd`
fi
QMF2_LIBS=$QMF2_HOME/build/lib
CLASSPATH=$QMF2_LIBS/qpid-client-patch.jar:$CLASSPATH:$QMF2_LIBS/qmf2.jar
# Get the log level from the AMQJ_LOGGING_LEVEL environment variable.
if [ -n "$AMQJ_LOGGING_LEVEL" ]; then
PROPERTIES=-Damqj.logging.level=$AMQJ_LOGGING_LEVEL
fi
cygwin=false;
case "`uname`" in
CYGWIN*) cygwin=true;;
esac
if $cygwin; then
CLASSPATH=$(cygpath -wp $CLASSPATH)
fi
java -cp $CLASSPATH $PROPERTIES
org.apache.qpid.qmf2.tools.ConnectionAudit "$@"
On 05/03/14 14:30, Jan Bares wrote:
> The shell scripts (/bin folder) use Windows EOLs and Cygwin's bash doesn't like it:
>
> $ ./ConnectionAudit.sh
> ./ConnectionAudit.sh: line 20: $'\r': command not found
> ./ConnectionAudit.sh: line 36: syntax error: unexpected end of file
>
> Switch to Unix EOL solves the problem.
>
> Please add support for Cygwin: https://issues.apache.org/jira/browse/QPID-5604
>
> Kind regards, Jan
>
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>> Sent: Wednesday, March 05, 2014 12:10 PM
>> To: users@qpid.apache.org
>> Subject: Re: QPID C++ broker monitoring and management
>>
>> On 03/05/2014 09:55 AM, Jan Bares wrote:
>>>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>> Thanks. I see there are some problems with Cygwin compatibility, where
>> can I post patches or suggestions?
>>
>> You can use JIRA and or this list (there is a 'Java Tools' component in
>> JIRA). For patches a JIRA is best, but feel free to post an accompanying
>> email to this list as well.
>>
>> Thanks in advance for any suggestions or improvements!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>
>
>
> DISCLAIMER
> ________________________________
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
The shell scripts (/bin folder) use Windows EOLs and Cygwin's bash doesn't like it:
$ ./ConnectionAudit.sh
./ConnectionAudit.sh: line 20: $'\r': command not found
./ConnectionAudit.sh: line 36: syntax error: unexpected end of file
Switch to Unix EOL solves the problem.
Please add support for Cygwin: https://issues.apache.org/jira/browse/QPID-5604
Kind regards, Jan
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Wednesday, March 05, 2014 12:10 PM
> To: users@qpid.apache.org
> Subject: Re: QPID C++ broker monitoring and management
>
> On 03/05/2014 09:55 AM, Jan Bares wrote:
> >> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
> >
> > Thanks. I see there are some problems with Cygwin compatibility, where
> can I post patches or suggestions?
>
> You can use JIRA and or this list (there is a 'Java Tools' component in
> JIRA). For patches a JIRA is best, but feel free to post an accompanying
> email to this list as well.
>
> Thanks in advance for any suggestions or improvements!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
Thanks Fraser, I agree with your points including fingers :-) Using ACLs is the right way, I am still learning new features of QPID.
Kind regards, Jan
> Hi Jan,
> There are no *plans* as such - mainly due to limited time and the fact
> that it hasn't been a priority for me (I'm trying to focus on getting a
> JavaScript implementation of AMQP 1.0 sorted and get my head around
> AMQP
> 1.0 Management)
>
> I agree that it's potentially useful. There is some fairly basic
> authentication as you might have discovered, it literally uses
> BasicAuthentication which has tended to be good enough for me as I only
> tend to need to use it on a private network.
>
> It's worth mentioning that you can configure the default connection
> using any valid Java ConnectionURL and if you simply use the configured
> default AMQP connection that info doesn't pass over the network to the
> UI (in that case it just uses "" as the URL) so if you're only managing
> a single broker it's not necessarily as insecure as you'd think given
> just basic authentication (that's partly why I've never really had to do
> more).
>
> That doesn't help you with your read only/read/write users thing though.
> I have toyed with "admin" and "normal" users, but I'm afraid I've never
> got around to it. I'm guessing that you want to restrict read only users
> to prevent them adding and deleting queues/exchanges.
>
> As a nasty hack (sorry!) you might be able to fire up two instances of
> the QpidRestAPI on different ports.
>
> What you'd need to do is copy the qpid-web subdirectory, but in there in
> "authentication/account.properties" is where the username and password
> stuff is held. If you have one instance as "admin" and another say as
> "user" you can specify the web root when you start up QpidRestAPI.
>
> Now if you were to do that then you could specify different connection
> URLs for each instance (with different Qpid usernames and passwords) and
> then use Qpid's ACL mechanism to prevent adding and deleting queues etc.
> from the "user" Connection.
>
> As I say it is a bit of a nasty hack, but I think that it it technically
> possible (I'm no expert on Qpid authentication and ACLs though) - and in
> practice it might *actually* be what you'd want anyway (depending on
> your level of paranoia) because even if the GUI were to have a mechanism
> to do what you suggest someone could still add/delete stuff via
> qpid-config or (if they were sufficiently knowledgeable) directly via
> the QMF protocol. (and they could certainly at least add
> queues/exchanges using a suitably constructed Address String).
>
> Personally I'd just threaten to break their fingers if they messed with
> my broker ;-D
>
>
> I'm going to have to get stuck into it again when I look to try and do
> something with AMQP 1.0 Management so I'll definitely give it some
> thought, but I can't promise timescales at the moment I'm afraid.
>
> Regards,
> Frase
>
>
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
There are no *plans* as such - mainly due to limited time and the fact
that it hasn't been a priority for me (I'm trying to focus on getting a
JavaScript implementation of AMQP 1.0 sorted and get my head around AMQP
1.0 Management)
I agree that it's potentially useful. There is some fairly basic
authentication as you might have discovered, it literally uses
BasicAuthentication which has tended to be good enough for me as I only
tend to need to use it on a private network.
It's worth mentioning that you can configure the default connection
using any valid Java ConnectionURL and if you simply use the configured
default AMQP connection that info doesn't pass over the network to the
UI (in that case it just uses "" as the URL) so if you're only managing
a single broker it's not necessarily as insecure as you'd think given
just basic authentication (that's partly why I've never really had to do
more).
That doesn't help you with your read only/read/write users thing though.
I have toyed with "admin" and "normal" users, but I'm afraid I've never
got around to it. I'm guessing that you want to restrict read only users
to prevent them adding and deleting queues/exchanges.
As a nasty hack (sorry!) you might be able to fire up two instances of
the QpidRestAPI on different ports.
What you'd need to do is copy the qpid-web subdirectory, but in there in
"authentication/account.properties" is where the username and password
stuff is held. If you have one instance as "admin" and another say as
"user" you can specify the web root when you start up QpidRestAPI.
Now if you were to do that then you could specify different connection
URLs for each instance (with different Qpid usernames and passwords) and
then use Qpid's ACL mechanism to prevent adding and deleting queues etc.
from the "user" Connection.
As I say it is a bit of a nasty hack, but I think that it it technically
possible (I'm no expert on Qpid authentication and ACLs though) - and in
practice it might *actually* be what you'd want anyway (depending on
your level of paranoia) because even if the GUI were to have a mechanism
to do what you suggest someone could still add/delete stuff via
qpid-config or (if they were sufficiently knowledgeable) directly via
the QMF protocol. (and they could certainly at least add
queues/exchanges using a suitably constructed Address String).
Personally I'd just threaten to break their fingers if they messed with
my broker ;-D
I'm going to have to get stuck into it again when I look to try and do
something with AMQP 1.0 Management so I'll definitely give it some
thought, but I can't promise timescales at the moment I'm afraid.
Regards,
Frase
On 05/03/14 15:21, Jan Bares wrote:
> Are there any plans to include authorizations too? For me, and I hope for other users too, it would suffice to have read-only users and read/write (modify) users.
>
> Kind regards, Jan
>
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>> Sent: Wednesday, March 05, 2014 12:10 PM
>> To: users@qpid.apache.org
>> Subject: Re: QPID C++ broker monitoring and management
>>
>> On 03/05/2014 09:55 AM, Jan Bares wrote:
>>>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>> Thanks. I see there are some problems with Cygwin compatibility, where
>> can I post patches or suggestions?
>>
>> You can use JIRA and or this list (there is a 'Java Tools' component in
>> JIRA). For patches a JIRA is best, but feel free to post an accompanying
>> email to this list as well.
>>
>> Thanks in advance for any suggestions or improvements!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>
>
>
> DISCLAIMER
> ________________________________
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
Are there any plans to include authorizations too? For me, and I hope for other users too, it would suffice to have read-only users and read/write (modify) users.
Kind regards, Jan
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Wednesday, March 05, 2014 12:10 PM
> To: users@qpid.apache.org
> Subject: Re: QPID C++ broker monitoring and management
>
> On 03/05/2014 09:55 AM, Jan Bares wrote:
> >> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
> >
> > Thanks. I see there are some problems with Cygwin compatibility, where
> can I post patches or suggestions?
>
> You can use JIRA and or this list (there is a 'Java Tools' component in
> JIRA). For patches a JIRA is best, but feel free to post an accompanying
> email to this list as well.
>
> Thanks in advance for any suggestions or improvements!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Gordon Sim <gs...@redhat.com>.
On 03/05/2014 09:55 AM, Jan Bares wrote:
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>
> Thanks. I see there are some problems with Cygwin compatibility, where can I post patches or suggestions?
You can use JIRA and or this list (there is a 'Java Tools' component in
JIRA). For patches a JIRA is best, but feel free to post an accompanying
email to this list as well.
Thanks in advance for any suggestions or improvements!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: QPID C++ broker monitoring and management
Posted by Jan Bares <ja...@wood.cz>.
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
Thanks. I see there are some problems with Cygwin compatibility, where can I post patches or suggestions?
Regards, Jan
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QPID C++ broker monitoring and management
Posted by Robbie Gemmell <ro...@gmail.com>.
It would need to be done ad-hoc at present, the steps we use to generate
and deploy the maven artifacts using the Ant build for the components in
the main Java tree wont really work with the QMF bits because of the
differing layout and build they use.
This is something we will need to look at eventually as part of integrating
with the work being done on a Maven build for the main Java tree currently,
and especially as we then look to split the tree up going beyond that.
Unfortunately it will be a more involved process with the QMF bits as
unlike the main tree we will need to completely reorganise the existing
stuff in order to create a useful Maven build for them, so it wasn't
something I got to in my initial work or which Andrew has looked at yet in
continuing with it.
Robbie
On 4 March 2014 21:49, Jakub Scholz <ja...@scholz.cz> wrote:
> It would be also nice to have the Java QMF library uploaded to Maven
> repositories similarly to the Java client. But I`m not sure how complicated
> that would be.
>
> Thanks & Regards
> Jakub
>
>
> On Tue, Mar 4, 2014 at 10:25 PM, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 03/04/2014 06:19 PM, Fraser Adams wrote:
> >
> >> I had *assumed* that because it was was on trunk it would be on a
> >> release - so I'm a bit confused if I'm honest.
> >>
> >> I've just checked and the first branch it's officially in is
> >>
> >> https://svn.apache.org/repos/asf/qpid/branches/0.24/
> >>
> >
> > Sorry, my mistake. As there wasn't a specific release component for it, I
> > assumed it wasn't released. I tend to overlook the full source bundle as
> I
> > don't use it much myself.
> >
> > Might be nice to have it as a standalone bundle to better highlight that
> > it is available. Also need to update the web site.
> >
> >
> > Which is what I'd expect, not really sure what the score is with
> >> releases, I tend to build from source.
> >>
> >> I looked in the downloads section http://qpid.apache.org/download.html
> >> at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
> >> python stuff in there currently whereas there are ruby and java
> >> subdirectories of tools/src now too.
> >>
> >> Frase
> >>
> >> On 04/03/14 11:39, Gordon Sim wrote:
> >>
> >>> On 03/04/2014 08:48 AM, Jan Bares wrote:
> >>>
> >>>> Is there any GUI based (web based) QPID management tool?
> >>>>
> >>>
> >>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
> >>> offer it in the releases yet (something we can fix soon perhaps,
> >>> Justin, Fraser?), but you can get it from trunk (or any of the release
> >>> branches if you prefer):
> >>>
> >>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
> >>>
> >>> I was looking at QMF and I have to say I don't understand what this
> >>>> tool doe.
> >>>>
> >>>
> >>> QMF is merely the mechanism that management tools use. It is a
> >>> protocol on top of AMQP for managing things through sending and
> >>> receiving messages of a particular format.
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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: QPID C++ broker monitoring and management
Posted by Jakub Scholz <ja...@scholz.cz>.
It would be also nice to have the Java QMF library uploaded to Maven
repositories similarly to the Java client. But I`m not sure how complicated
that would be.
Thanks & Regards
Jakub
On Tue, Mar 4, 2014 at 10:25 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/04/2014 06:19 PM, Fraser Adams wrote:
>
>> I had *assumed* that because it was was on trunk it would be on a
>> release - so I'm a bit confused if I'm honest.
>>
>> I've just checked and the first branch it's officially in is
>>
>> https://svn.apache.org/repos/asf/qpid/branches/0.24/
>>
>
> Sorry, my mistake. As there wasn't a specific release component for it, I
> assumed it wasn't released. I tend to overlook the full source bundle as I
> don't use it much myself.
>
> Might be nice to have it as a standalone bundle to better highlight that
> it is available. Also need to update the web site.
>
>
> Which is what I'd expect, not really sure what the score is with
>> releases, I tend to build from source.
>>
>> I looked in the downloads section http://qpid.apache.org/download.html
>> at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
>> python stuff in there currently whereas there are ruby and java
>> subdirectories of tools/src now too.
>>
>> Frase
>>
>> On 04/03/14 11:39, Gordon Sim wrote:
>>
>>> On 03/04/2014 08:48 AM, Jan Bares wrote:
>>>
>>>> Is there any GUI based (web based) QPID management tool?
>>>>
>>>
>>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
>>> offer it in the releases yet (something we can fix soon perhaps,
>>> Justin, Fraser?), but you can get it from trunk (or any of the release
>>> branches if you prefer):
>>>
>>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>>
>>> I was looking at QMF and I have to say I don't understand what this
>>>> tool doe.
>>>>
>>>
>>> QMF is merely the mechanism that management tools use. It is a
>>> protocol on top of AMQP for managing things through sending and
>>> receiving messages of a particular format.
>>>
>>> ---------------------------------------------------------------------
>>> 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: QPID C++ broker monitoring and management
Posted by Gordon Sim <gs...@redhat.com>.
On 03/04/2014 06:19 PM, Fraser Adams wrote:
> I had *assumed* that because it was was on trunk it would be on a
> release - so I'm a bit confused if I'm honest.
>
> I've just checked and the first branch it's officially in is
>
> https://svn.apache.org/repos/asf/qpid/branches/0.24/
Sorry, my mistake. As there wasn't a specific release component for it,
I assumed it wasn't released. I tend to overlook the full source bundle
as I don't use it much myself.
Might be nice to have it as a standalone bundle to better highlight that
it is available. Also need to update the web site.
> Which is what I'd expect, not really sure what the score is with
> releases, I tend to build from source.
>
> I looked in the downloads section http://qpid.apache.org/download.html
> at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
> python stuff in there currently whereas there are ruby and java
> subdirectories of tools/src now too.
>
> Frase
>
> On 04/03/14 11:39, Gordon Sim wrote:
>> On 03/04/2014 08:48 AM, Jan Bares wrote:
>>> Is there any GUI based (web based) QPID management tool?
>>
>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
>> offer it in the releases yet (something we can fix soon perhaps,
>> Justin, Fraser?), but you can get it from trunk (or any of the release
>> branches if you prefer):
>>
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>
>>> I was looking at QMF and I have to say I don't understand what this
>>> tool doe.
>>
>> QMF is merely the mechanism that management tools use. It is a
>> protocol on top of AMQP for managing things through sending and
>> receiving messages of a particular format.
>>
>> ---------------------------------------------------------------------
>> 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: QPID C++ broker monitoring and management
Posted by Robbie Gemmell <ro...@gmail.com>.
It is included in the full source release,
http://www.apache.org/dyn/closer.cgi/qpid/0.26/qpid-0.26.tar.gz , it just
hasn't got its own separate archive.
Robbie
On 4 March 2014 18:19, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> I had *assumed* that because it was was on trunk it would be on a release
> - so I'm a bit confused if I'm honest.
>
> I've just checked and the first branch it's officially in is
>
> https://svn.apache.org/repos/asf/qpid/branches/0.24/
>
> Which is what I'd expect, not really sure what the score is with releases,
> I tend to build from source.
>
> I looked in the downloads section http://qpid.apache.org/download.html at
> qpid-tools-0.26.tar.gz and noticed that this only seems to have the python
> stuff in there currently whereas there are ruby and java subdirectories of
> tools/src now too.
>
> Frase
>
>
> On 04/03/14 11:39, Gordon Sim wrote:
>
>> On 03/04/2014 08:48 AM, Jan Bares wrote:
>>
>>> Is there any GUI based (web based) QPID management tool?
>>>
>>
>> Yes, Fraser Adams built a web based console for QMF. We don't seem to
>> offer it in the releases yet (something we can fix soon perhaps, Justin,
>> Fraser?), but you can get it from trunk (or any of the release branches if
>> you prefer):
>>
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>>
>> I was looking at QMF and I have to say I don't understand what this tool
>>> doe.
>>>
>>
>> QMF is merely the mechanism that management tools use. It is a protocol
>> on top of AMQP for managing things through sending and receiving messages
>> of a particular format.
>>
>> ---------------------------------------------------------------------
>> 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: QPID C++ broker monitoring and management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
I had *assumed* that because it was was on trunk it would be on a
release - so I'm a bit confused if I'm honest.
I've just checked and the first branch it's officially in is
https://svn.apache.org/repos/asf/qpid/branches/0.24/
Which is what I'd expect, not really sure what the score is with
releases, I tend to build from source.
I looked in the downloads section http://qpid.apache.org/download.html
at qpid-tools-0.26.tar.gz and noticed that this only seems to have the
python stuff in there currently whereas there are ruby and java
subdirectories of tools/src now too.
Frase
On 04/03/14 11:39, Gordon Sim wrote:
> On 03/04/2014 08:48 AM, Jan Bares wrote:
>> Is there any GUI based (web based) QPID management tool?
>
> Yes, Fraser Adams built a web based console for QMF. We don't seem to
> offer it in the releases yet (something we can fix soon perhaps,
> Justin, Fraser?), but you can get it from trunk (or any of the release
> branches if you prefer):
>
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
>
>> I was looking at QMF and I have to say I don't understand what this
>> tool doe.
>
> QMF is merely the mechanism that management tools use. It is a
> protocol on top of AMQP for managing things through sending and
> receiving messages of a particular format.
>
> ---------------------------------------------------------------------
> 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: QPID C++ broker monitoring and management
Posted by Gordon Sim <gs...@redhat.com>.
On 03/04/2014 08:48 AM, Jan Bares wrote:
> Is there any GUI based (web based) QPID management tool?
Yes, Fraser Adams built a web based console for QMF. We don't seem to
offer it in the releases yet (something we can fix soon perhaps, Justin,
Fraser?), but you can get it from trunk (or any of the release branches
if you prefer):
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
> I was looking at QMF and I have to say I don't understand what this tool doe.
QMF is merely the mechanism that management tools use. It is a protocol
on top of AMQP for managing things through sending and receiving
messages of a particular format.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org