JDK-6190873 : JMX lacks thread control interface
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-11-04
  • Updated: 2017-05-16
  • Resolved: 2004-12-16
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.
Other JDK 6
5.0u2 b04Fixed 6Fixed
Description
It has been determined that JMX1.2 spawns a bunch of threads (could be 100's in large WLS deployments) which are taking up resources (i.e. thread pools, memory, and such) and these threads are not managed by the J2EE container. JMX1.2 doesn't provide a way for controlling of threads from outside of JMX. This has significant negative impact on performance, tuning, and scalability.

The specific area where this is problematic for BEA is the thread that is created for each JMX Connector Client to pick up notifications from the remote server.  If there were a way to execute the fetchNotifications request from within a thread in a user-supplied thread pool, that would suffice for the immediate problem.
###@###.### 11/4/04 18:55 GMT
Comments
EVALUATION Proposed fix is to add a property in the Map supplied when creating a connector client, that is a java.util.concurrent.Executor to be used to run the fetchNotifications operation that picks up notifications from the remote server. The Executor could also be used to run the "heartbeat", i.e. regularly scheduled pings, if it is a ScheduledExecutorService. ###@###.### 2004-11-05 13:03:23 GMT
04-11-2004