You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Mark Ford (JIRA)" <ji...@apache.org> on 2010/11/10 17:47:19 UTC
[jira] Created: (CAMEL-3325) camel-jmx: Auto creation of a monitor
bean via endpoint properties
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.
Re: [jira] Created: (CAMEL-3325) camel-jmx: Auto creation of a
monitor bean via endpoint properties
Posted by Claus Ibsen <cl...@gmail.com>.
I have created the camel-jmx category
On Wed, Nov 10, 2010 at 7:07 PM, Mark Ford <ma...@massfords.com> wrote:
> There should be a component category in JIRA for camel-jmx
>
> As for this issue, I have some code that's mostly working. I'll be
> putting the finishing touches on over the course of the next couple of
> weeks as time permits. Any input on the feature is appreciated.
>
> On Wed, Nov 10, 2010 at 11:47 AM, Mark Ford (JIRA) <ji...@apache.org> wrote:
>> 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.
>>
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [jira] Created: (CAMEL-3325) camel-jmx: Auto creation of a
monitor bean via endpoint properties
Posted by Mark Ford <ma...@massfords.com>.
There should be a component category in JIRA for camel-jmx
As for this issue, I have some code that's mostly working. I'll be
putting the finishing touches on over the course of the next couple of
weeks as time permits. Any input on the feature is appreciated.
On Wed, Nov 10, 2010 at 11:47 AM, Mark Ford (JIRA) <ji...@apache.org> wrote:
> 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.
>
>
[jira] Updated: (CAMEL-3325) camel-jmx: Auto creation of a monitor
bean via endpoint properties
Posted by "Mark Ford (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Ford updated CAMEL-3325:
-----------------------------
Component/s: camel-jmx
Affects Version/s: 2.6.0
> 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
> Components: camel-jmx
> Affects Versions: 2.6.0
> 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.