Hi All,
I have done some work in the JMX interface. Please commit the patch to the url:
It uses the management classes https://svn.apache.org/repos/asf/webservices/axis2/trunk/archive/java/scratch/Axis_Management_module/management/src/org/apache/axis2/management/core/managers/
) and exposes thier interfaces using MBeans.
Still it supports only configuration and monitoring functions, but not notifications.
It uses 5 MBeans for configuring functions and below 3 MBeans for monitoring functions.
1) Entire engine - DynamicStatsManagerMBean
2) Services - AxisServiceStatsMBean
3) Operations - AxisOperationStatsMBean
These MBeans allow monitoring number of in messages, out messages, in fault messages and out fault messages at above 3 levels. As it uses single MBean to represent all services, we have provide the service name to get its statistics. Therefore, AxisServiceStatsMBean has set of MBean operations which take service name as the parameter, rather than having set of MBean attributes. This is same for AxisOperationStatsMBean as well. Is this ok?
If we want to have statistics as MBean attributes, we can instantiate an MBean per each service by providing service name for the constructor and register them with the service name. But this results in large number of MBeans as we have to have an MBean per each service and each operation. Which approach is better?
Please let me know, what changes have to be done to use this with real management application, specailly with SmartFrog.
I will start work on the notification ASAP. What are the possible events that should emmit notifications.
e.g. Exceeding the in message count over 500
Chathura.
On 3/22/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Hmm, i had done something similar in Axis1 using Commons Modeler.
-- dims
On 3/22/06, Sanjiva Weerawarana < [EMAIL PROTECTED]> wrote:
> Having an MBean means it can be managed by any JMX platform .. so lots
> of value there.
>
> IIRC Dims did commit some code like that. Dims??
>
> Sanjiva.
>
> On Wed, 2006-03-22 at 17:58 +0600, Deepal Jayasinghe wrote:
> > well we have something similar to that :)
> >
> > and you can do that by adding Observers into Axis2. And there was a GSOC
> > project which used that technique.
> >
> > Soumadeep wrote:
> >
> > >Sanjiva,
> > >
> > >Wasn't aware of Chathura's situation, I do appreciate his efforts.
> > >
> > >>From an axis2 perspective can we at least have a Management Mbean, which can
> > >broadcast notifications so that any external application can listen to
> > >events generated by ASIX2 by registering to that Mbean?
> > >
> > >Thanks
> > >Soumadeep
> > >
> > >-----Original Message-----
> > >From: Sanjiva Weerawarana [mailto: [EMAIL PROTECTED]]
> > >Sent: Wednesday, March 22, 2006 5:12 PM
> > >To: [email protected]
> > >Subject: Re: [Axis2] Management Interface
> > >
> > >On Wed, 2006-03-22 at 11:16 +0000, Steve Loughran wrote:
> > >
> > >
> > >>Hey, I have that @work too. Proxies, you understand.
> > >>I have to put my laptop up on the WLAN as a guest for the day, which
> > >>means going to the
> > >>appropriate IT page and registering a guest (me) under the supervision
> > >>of an employee (me)
> > >>
> > >>
> > >
> > >At least when I was in IBM they were very intelligent about this ..
> > >clearly HPLabs is still living in the dark ages of the Internet ;-).
> > >
> > >Unfortunately U of Moratuwa doesn't have a model to make this work
> > >easily .. the only option is to get an account on a specific machine
> > >which has more access and set up multiple ssh tunnels etc.. Its not
> > >impossible but a total PITA. When you are struggling to keep up with
> > >coursework and also do this stuff for fun, its really hard to see the
> > >fun of it.
> > >
> > >No I'm not excusing him however .. I'm supervising his final year
> > >project so he is of course expected to contrib stuff here ;-). TCP does
> > >work over carrier pigeons too, so really there's not much of an
> > >excuse! ;-)
> > >
> > > http://en.wikipedia.org/wiki/User:Chronographos/Pigeon-implemented_TCP/IP
> > >
> > >
> > >
> > >>Usually committer access is a bit easier because HTTPS is less likely to
> > >>be fiddled with at the gate
> > >>
> > >>
> > >
> > >These guys even shut down 443. :(.
> > >
> > >Sanjiva.
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
axis2management2.patch
Description: Binary data
