camel-jmx: Auto creation of a monitor bean via endpoint properties
------------------------------------------------------------------
Key: CAMEL-3325
URL: https://issues.apache.org/activemq/browse/CAMEL-3325
Project: Apache Camel
Issue Type: New Feature
Reporter: Mark Ford
Priority: Minor
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.
