[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    JMX notifications from MC4J/EMS
From:       genman () noderunner ! net (Elias Ross)
Date:       2011-06-02 19:42:54
Message-ID: BANLkTikUNsanS4p4dhn-7NjMJjY2hhKAWw () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 13, 2011 at 2:08 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:

> Hei Elias,
>
>> So I'm considering adding support for JMX notifications in RHQ.
>
> Great!
>
>> 1. For each EmsBean.getNotifications() (returns set of interface
>> EmsNotification).
>> 2. Determine if we should listen or not to its notifications (through
>> configuration? always?) Not sure how to indicate in XML this detail.
>
> The Events subsystem supports the notion of even sources, that the user can
> enable in the UI. A resource can have multiple event sources. So this could
> be somehow be taken to determine the notifications to listen to.
>
> So I guess there are two choices here to be made:
>
> - which object names to listen to? A resource in RHQ could encompass
> multiple MBeans

I'm thinking if you have multiple MBeans under a <service>, you would
have one EventSource. The ObjectName would appear under the Event
itself.

I'm not sure how to build the Event. Probably like:

ObjectName on;
Notification n;
EventSeverity severity = EventSeverity.INFO; /* Or set from configuration? */

Event event = new Event(m.getType(), on.toString(), m.getTimeStamp(),
severity, m.getMessage());

Not sure what to do with n.getUserData() ?

Severity could be mapped from the type of notification

> - which notification filters to apply

In terms of configuration, I was considering something like:

See:
http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/MemoryNotificationInfo.html

      <service name="VM Memory System" ...>

         <plugin-configuration>
...
            <c:simple-property name="notifications" default="true"/>
            <c:simple-property name="notificationError"
default="java.management.memory.threshold"/>
            <c:simple-property name="notificationWarn"
default="java.management.memory.something"/>
            <c:simple-property name="notificationFilter"
default="java.management.memory.threshold.*"/>

Since RHQ already has a notion of event filtering, I don't know if a
filter here is useful ?

It looks like it becomes a hassle to set error/warn/info by
configuration and maybe not a useful feature either. Can RHQ translate
a notification from INFO -> ERROR?

>
> For the very generic case of one MBean only, the object name would be the
> one of the Mbean and the filter could be delivered from the UI in the EventSource

Yes.

> See also org.rhq.core.domain.event.EventSource
>
> I think you are on the right track.

Any comments on changes to MC4J/EMS I'm proposing?

DNotification will need changing to add support for event listeners.
Currently it just accumulates objects; a potential memory leak, for
sure.

This is pretty much my first change I need.

[prev in list] [next in list] [prev in thread] [next in thread]