You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2010/12/31 09:57:47 UTC

[jira] Assigned: (CAMEL-3325) camel-jmx: Auto creation of a monitor bean via endpoint properties

     [ https://issues.apache.org/jira/browse/CAMEL-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-3325:
----------------------------------

    Assignee: Christian Müller

Christian do you have time to look into this patch?

> camel-jmx: Auto creation of a monitor bean via endpoint properties
> ------------------------------------------------------------------
>
>                 Key: CAMEL-3325
>                 URL: https://issues.apache.org/jira/browse/CAMEL-3325
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-jmx
>    Affects Versions: 2.6.0
>            Reporter: Mark Ford
>            Assignee: Christian Müller
>            Priority: Minor
>         Attachments: camel-3325-patch-sans-lang.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.