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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < > > [EMAIL PROTECTED]> 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... !
