camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Ford (JIRA)" <>
Subject [jira] Updated: (CAMEL-3325) camel-jmx: Auto creation of a monitor bean via endpoint properties
Date Thu, 30 Dec 2010 18:48:01 GMT


Mark Ford updated CAMEL-3325:

    Attachment: camel-3325-patch.txt

The patch provides for all of the functionality described in the issue when connecting to
the platform server. A remote server is problematic since it requires a library (JMXRemote)
on both the client and the server and I don't think it's worth pursuing at this time.

Some notes for commits:
main src
- JMXConsumer: extracted add/removeNotificationListener methods to allow for override
- JMXEndpoint: added new uri properties for monitor type consumer
- JMXMonitorConsumer: new type of consumer that adds a monitor bean to monitor the specified
- JMXUriBuilder: added monitor type properties

- new tests for monitor consumer
- extracted various assertions to MockEndpointFixture
- added new property to test SimpleBean to allow for counter and gauge monitors

> camel-jmx: Auto creation of a monitor bean via endpoint properties
> ------------------------------------------------------------------
>                 Key: CAMEL-3325
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-jmx
>    Affects Versions: 2.6.0
>            Reporter: Mark Ford
>            Priority: Minor
>         Attachments: camel-3325-patch.txt
> The current version of the camel-jmx component allows for the forwarding of JMX notifications
from an mbean into the route. In addition to receiving notifications, a user may want to monitor
an mbean. The consumer currently doesn't have any special handling for monitor beans. The
user would need to write a few lines of Java code to create their monitor and deploy it. Once
deployed, the monitor bean could use the objectName for the monitor bean in conjunction with
the camel-jmx component to forward events into the route.
> For example:
> {code:java}
> CounterMonitor monitor = new CounterMonitor();
> monitor.addObservedObject(makeObjectName("simpleBean"));
> monitor.setObservedAttribute("MonitorNumber");
> monitor.setNotify(true);
> monitor.setInitThreshold(1);
> monitor.setGranularityPeriod(500);
> registerBean(monitor, makeObjectName("counter"));
> monitor.start();
> {code} 
> The proposed new feature is to add a new type of consumer that automatically creates
and registers a monitor bean for the specified objectName and attribute. Additional endpoint
attributes would be added to allow the user to specify the attribute to monitor, type of monitor
to create, and any other required properties. The code snippet above could be condensed into
a set of endpoint properties. The consumer would use these properties to create the CounterMonitor,
register it, and then subscribe to its changes.
> For example:
> {code:java}
> from("jmx:platform?objectDomain=myDomain&objectName=simpleBean&monitorType=counter&observedAttribute=MonitorNumber&initThreshold=1&granularityPeriod=500").to("mock:sink");
> {code}
> New endpoint attributes:
> ||property||type||applies to||description||
> | monitorType |enum| all |  one of counter, guage, string |
> | observedAttribute |string| all | the attribute being observed |
> | granualityPeriod |long| all | granularity period (in millis) for the attribute being
observed. As per JMX, default is 10 seconds |
> | initThreshold |number| counter | initial threshold value |
> | offset |number| counter | offset value |
> | modulus |number| counter | modulus value |
> | differenceMode | boolean | counter, gauge | true if difference should be reported,
false for actual value |
> | notifyHigh | boolean | gauge | high notification on/off switch |
> | notifyLow | boolean | gauge | low notification on/off switch |
> | highThreshold | number | gauge | threshold for reporting high notification |
> | lowThreshold | number | gauge | threshold for reporting low notificaton |
> | notifyDiffer | boolean | string | true to fire notification when string differs |
> | notifyMatch | boolean | string | true to fire notification when string matches |
> | stringToCompare | string | string | string to compare against the attribute value |

> Other considerations
> * If the mbeanserver is remote, then the JMXRemote library or similar solution is required
to register the monitor bean
> * name of the monitor bean should be derived from the observed object
> * if the observed bean is unregistered then the route should send some notification or
exception through its route to signal the processors

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message