Other Issues
The JMX monitoring services can be very useful in providing you with an off-the-shelf implementation of a notification broadcaster that is geared for watching attribute values. However, this convenience comes at a price.
First, a monitor can be used to watch only a single attribute of a single MBean. If you would like to monitor multiple resources in your application, you must create a monitor of the appropriate type for every attribute of every MBean you want to monitor.
Second, a monitor must watch the attribute value of an MBean in its own thread of execution, so that, regardless of what the application is doing, the monitor can “spy” on the attribute value and report the results accordingly. Thus, for every monitor, a new thread in the JVM running your application must be created.
Finally, in the JMX 1.0 RI, each time the granularity period elapses and the monitor thread checks the MBean attribute, that thread is replaced with an entirely new thread! This is an odd implementation and can be fairly resource-intensive, depending on which operating system your application runs and how efficiently thread creation and scheduling occurs.