qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lahiru gunathilake" <glah...@gmail.com>
Subject Re: GSoC - Lahiru's CLI for JMX
Date Sat, 03 May 2008 08:56:14 GMT
hi Martin and Marnie,

Yep I'm going through that code. I found a location where you have written
MBeans and i want to know is that the only location you have registered or
do you have several other places too.
This is the place
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/management

I will keep on looking if you know some other places please let  me know
that will be helpful for me to get a rough understanding about Qpid JMX
interface.

Thanks
lahiru




On Fri, May 2, 2008 at 6:11 PM, Martin Ritchie <ritchiem@apache.org> wrote:

> Hi, Marnie is away for a few days she may respond but just in case
> here are my thoughts so you are not held up over the weekend.
>
> On 01/05/2008, lahiru gunathilake <glahiru@gmail.com> wrote:
> > Hi,
> >
> >  First I'm very sorry for taking sometime to reply to your mail( because
> I
> >  was uable to be online for yesterday) and thanks a lot for writing me
> about
> >  the Gsoc project.
> >  Thats great and now I know, the image I had about the project is
> correct. I
> >  think I have to create a project plane(I realize it after having a chat
> with
> >  Aidan) and once I create it I will send it to you.
> >
> >  In order to create a clear project plan honestly could you please tell
> me
> >  what should I finish when it comes to mid evaluation. I'm sure, that
> will
> >  help me a lot to create a better road map.
> >
> >  Next thing.. Could you please look in to my inline comment.
> >
> >
> >  On Wed, Apr 30, 2008 at 12:13 AM, Marnie McCormack <
> >  marnie.mccormack@googlemail.com> wrote:
> >
> >  > Hi Lahiru,
> >  >
> >  > As promised here are my thoughts about what I'd like to achieve from
> the
> >  > project I defined for your GSoC work.
> >  >
> >  > So, currently we provide some JMX calls which expose various
> attributes in
> >  > the Qpid Java broker. We have users who are interested in these
> >  > attributes,
> >  > but there's currently no simple way for them to get access to them.
> >
> >
> >
> > Can I know exactly what are they(where are those attributes in the Qpid
> code
> >  base) . I can check them with Jconsole as a user. But as a developer
> can I
> >  know where that code located  and where is the code where it expose as
> JMX
> >  calls. (Honestly if this is a task which shoud be done by my self just
> give
> >  me a clue and I will find where are those )
>
> Have a look for all the MBean classes these are the bits that show up
> in JConsole.
>
> >
> >  > They can
> >  > view them on the management console (assuming they can get it working
> :-),
> >  > they can attach some other monitoring GUI or proprietary application.
> >  >
> >  > For some of our JMX props, they can be set up to log alerts to the
> broker
> >  > log - which can again be monitored.
> >  >
> >  > However, it would be really useful if they could simply use a CLI
> tool to
> >  > extract the information they're looking for.
> >
> > > +1
> >
> > > I had envisaged it taking a really simple form:
> >  >
> >  >   - a shell script (bash or .bat) to call the CLI tool, probably
> simply
> >  >   wrapping a java call, which will run as a daemon (or service)
> >  >   - a config/properties file or command line options to specify:
> >  >      - the JMX attribute to extract
> >  >      - the frequency with which to extract it, in minutes (i.e. an
> >  >      elapsed time between extraction like 5 minutes)
> >
> >
> > If the time is five minutes then if the deamon runs one hour the CLI
> outputs
> >  around 12 out put information.
> >  As an example CLI should write 12 out put files to a give location. Am
> I
> >  correct .. ?
>
> I would say it would write 12 times to single file that has been
> specified.
> Potentially you could configure various logging information to go to a
> variety of files, but I'd start with a single configurable file.
>
> >  >
> >  >      - a path into which to record the output
> >  >      - an option for the output format (see my proposal info about
> >  >      formatting etc) like csv, tab-delimited, html etc. This might be
> >  > better done
> >
> >
> > Can be done..!
> >
> >
> >  >
> >  >      as optional export into another tool ?
> >  >
> >
> >  >   - the properties/config should be extensible so that new attributes
> >  >   implemented in the broker can easily be added
> >
> > > Sure.. this should be in that way.
> >
> > > So, when a user wants to get useful management information from the
> broker
> >  > (but not using a GUI) they can simply create a props file and voila !
> >
> >
> > Not much clear this statement. "create props file and voila!"
>
> I think what Marnie is saying is that what would be good is for a user
> to specify a property file that contains the information they are
> after so when they run the command line tool it will simply return
> that. If they wished that property file could be used by the daemon
> process to populate the logfile.
>
> >
> >  >
> >  >  What do you think ? Does this make sense to you ok ?
> >
> >
> > Exactly this is the best description I got about my project and thanks a
> lot
> >  for your great assist.
> >
> >
> >  >
> >  > I'll reply to your email about issues shortly, in a separate email.
> >  >
> >  > Hth,
> >  > Thanks & Regards,
> >  > Marnie
> >  >
> >
> > Thanks in advance
> >
> >  Regs
> >
> > lahiru
> >
>
>
> --
> Martin Ritchie
>



-- 
East or West
Mahindians are the
Best... !

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message