qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack" <marnie.mccorm...@googlemail.com>
Subject Re: GSoC - Lahiru's CLI for JMX
Date Sun, 04 May 2008 08:15:07 GMT
Hi Lahiru,

Here's an email I prepared on Wed evening but didn't get a chance to send -
I hope it helps with your query on the codebase/mbeans. I'm out of the
office this week for personal reasons, but I'll try to login as I can and
keep up to date with your progress.

Re your question on mid evaluation, why don't we discuss that when we next
talk. I'd hope I'll be able to call you later this week, but I'll confirm by
email to you. Apologies for the slight blip in communication, it should be
very temporary.

Hth ....


Hi Lahiru,


As a starting point, you should have a look at the AMQManagedObject
interface which is implemented by all classes exposing management
methods/attributes. If you search for derived classes (implementing classes)
you'll see the set of entities which provide attributes for JMX calls.

In particular, the ManagedQueue interface in package
org.apache.qpid.server.queue contains a substantial amount of the exposed
attributes. This is where the attributes exposed on the broker's queues are
described. AMQQueueMBean (same package) implements this interface. This is
the best place to get a handle on the queue attributes exposed via JMX.

I think a useful first step would be to list out the elements provided via
JMX on the broker, and note where they are implemented in the code. The
usage of the various elements will differ, in terms of the frequency with
which a user might want to check them etc. I hope this would be a useful
start ! We can then discuss whether the detail I sent previously about the
parameters for running the CLI scripts are appropriate.

The management console sholdn't inform much of what your doing, in terms of
being a template. However, it might make it easier for you to understand the
various elements provided. Martin & Aidan should be able to help you get it
up & running. Martin/Aidan - can you can help Lahiru with this please ?
Thanks !

Senaka's emails on the console setup help a little, though possibly not so
relevant to a windows env ?

Hth,
Regards,
Marnie



On 5/3/08, lahiru gunathilake <glahiru@gmail.com> wrote:
>
> 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