JMX MBean Operations limitation
I am a production customer running Applications Manager build 8200 on linux.
As my previous post on a different JMX-related topic mentioned, we are heavily dependent on JMX within our monitoring infrastructure. We have instrumented our distributed Java-based application with significant amounts of JMX operations and attributes to make remote management and monitoring a possibility.
The support for MBean Operations within a "JMX Applications" type monitor has an aspect to its design that renders it more difficult to use. Specifically, a configured MBean Operation in Applications Manager presents two options for execution:
1. The Execute button which executes the operation using the first value specified in the operation's configuration for each parameter.
2. The Manual Execution button which pops up a window allowing the user to choose from a pre-configured list of values (comma-separated in the operation's config) for each parameter.
MBean Operations are allowed to be Action Types. I'm assuming that the MBean Operation support was designed with that use-case primarily in mind. In other words, when an alert occurs, an MBean Operation can automatically be executed by Applications Manager. In this use case, having a fixed set of parameter values is appropriate given the automatic execution of the operation.
There is another use case that is very common for us, but is not covered well in Applications Manager as it stands today. Specifically, we need the ability to dynamically parameterize calls to MBean Operations (i.e., explicitly type in parameter values rather than choose them from a preconfigured set of values). An example might help:
If a support person receives an alert that a file is stuck on a remote node due to a network issue, the support person works on the root cause and eventually fixes it. At this point, the support person needs to send a message to the remote node (i.e., remote Java VM) that the stuck file may now continue on its way. We've implemented that message as a JMX MBean Operation that may have a signature like this:
void restartFile(int fileID)
Note that the parameter value cannot be preconfigured because it will be unknown to the user (at MBean Operation creation time) what fileIDs will need to be specified. As such, we need the ability to type in at MBean Operation execution time the values of all parameters, and have that specific invocation occur with those parameter values (not saving the parameter values for later).
Current work-arounds include either editing the MBean Operation configuration every time we want to invoke it with "dynamic" values, or utilizing the JDK's JConsole tool (which supports dynamic parameterization). Both of these work arounds are problematic from a training point of view and make our support staff more reticent to actively embrace Applications Manager as their main tool.
I would very much appreciate it if dynamic parameter value specification (i.e., specification at invocation time) for MBean Operations could be added soon to Applications Manager.
Thanks!
Brett Peterson
VisionShare, Inc.
As my previous post on a different JMX-related topic mentioned, we are heavily dependent on JMX within our monitoring infrastructure. We have instrumented our distributed Java-based application with significant amounts of JMX operations and attributes to make remote management and monitoring a possibility.
The support for MBean Operations within a "JMX Applications" type monitor has an aspect to its design that renders it more difficult to use. Specifically, a configured MBean Operation in Applications Manager presents two options for execution:
1. The Execute button which executes the operation using the first value specified in the operation's configuration for each parameter.
2. The Manual Execution button which pops up a window allowing the user to choose from a pre-configured list of values (comma-separated in the operation's config) for each parameter.
MBean Operations are allowed to be Action Types. I'm assuming that the MBean Operation support was designed with that use-case primarily in mind. In other words, when an alert occurs, an MBean Operation can automatically be executed by Applications Manager. In this use case, having a fixed set of parameter values is appropriate given the automatic execution of the operation.
There is another use case that is very common for us, but is not covered well in Applications Manager as it stands today. Specifically, we need the ability to dynamically parameterize calls to MBean Operations (i.e., explicitly type in parameter values rather than choose them from a preconfigured set of values). An example might help:
If a support person receives an alert that a file is stuck on a remote node due to a network issue, the support person works on the root cause and eventually fixes it. At this point, the support person needs to send a message to the remote node (i.e., remote Java VM) that the stuck file may now continue on its way. We've implemented that message as a JMX MBean Operation that may have a signature like this:
void restartFile(int fileID)
Note that the parameter value cannot be preconfigured because it will be unknown to the user (at MBean Operation creation time) what fileIDs will need to be specified. As such, we need the ability to type in at MBean Operation execution time the values of all parameters, and have that specific invocation occur with those parameter values (not saving the parameter values for later).
Current work-arounds include either editing the MBean Operation configuration every time we want to invoke it with "dynamic" values, or utilizing the JDK's JConsole tool (which supports dynamic parameterization). Both of these work arounds are problematic from a training point of view and make our support staff more reticent to actively embrace Applications Manager as their main tool.
I would very much appreciate it if dynamic parameter value specification (i.e., specification at invocation time) for MBean Operations could be added soon to Applications Manager.
Thanks!
Brett Peterson
VisionShare, Inc.