United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6190873 JMX lacks thread control interface
6190873 : JMX lacks thread control interface

Details
Type:
Enhancement
Submit Date:
2004-11-04
Status:
Resolved
Updated Date:
2010-07-29
Project Name:
JDK
Resolved Date:
2004-12-16
Component:
core-svc
OS:
generic
Sub-Component:
javax.management
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
5.0u2

Related Reports
Backport:

Sub Tasks

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
                                     
2004-11-04



Hardware and Software, Engineered to Work Together