JDK-6602699 : support for async notification of mbeaninfo update
- Type: Enhancement
- Component: core-svc
- Sub-Component: javax.management
- Affected Version: 6
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2007-09-10
- Updated: 2011-03-08
- Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 7 |
|---|
7 b40Fixed  |
Related Reports
|
Relates :
|
Description
JMX has the notion of mbean info containing meta-data about an mbean's signature. In the current JMX implementation there is the notion of descriptors allowing the user to describe mbean info as either immutable (can be cached) or mutable, and with mutable, the descriptor for a suggestion of caching interval for a client to use. It's very hard to calculate that interval! The suggestion is to introduce a new notification type, say, JMX.mbean.info.changed, that would allow the mbean to inform the layers above that its signature had changed in an asynchronous manner, and if this is supported, to have the notification type available in the notification info. That way, a caching layer could listen to these notifications to keep its mbean info up to date, instead of a fairly arbitrary cache-time-to-live policy. This could also have built-in support in the StandardEmitterMBean. It would be nice to be able to put the new MBeanInfo value in the mbean payload (UserData) to avoid a round-trip to collect the new value. This may involve mapping to open-data.
Comments
|