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 Thu, 01 May 2008 18:17:31 GMT
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 )

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

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

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

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