Known Limitations

The following issues are known limitations of the Java Dynamic Management Kit 4.1 product at the time this document is being published (April 2000). Here, we explain the observed inconsistencies and suggest a workaround:

SNMPv2 Protocol

Report PDUs are not supported in the Java Dynamic Management Kit 4.1 because they are not presently defined by the standards (RFC 1905). Trap PDUs (both v1 and v2) and InformRequests are fully supported and should be used to send management information between agents and mangers or between managers, respectively.

The mibgen Tool

The mibgen tool cannot handle the row status construct. No error is generated and MIB compilation is not interrupted, but no special support is provided for the semantics of RowStatus variables (as defined in RFC 1903).

ACL Syntax

The Java Dynamic Management Kit 4.1 does not support a manager and trap host name of the form hostname.domain in an ACL file. You must use the host's corresponding IP address.

The use of localhost (or the corresponding IP address 127.0.0.1) as host name is not fully supported. You should use the specific hostname or IP address instead.

The HTML Adaptor

Due to the limitations of the HTML protocol, the HTML adaptor does not provide the same management view as a connector. For example, you cannot set attributes individually in the MBean view--all setters are called every time the "Apply" button is selected, even if the content hasn't changed.

Also, the HTML adaptor can only represent a limited set of types through an HTML interface. The values of attribute or operation results which rely on an unsupported type cannot be displayed or entered by the user. This means that some component functionality is inaccessible through the HTML adaptor.

Connector Server States

When a connector server cannot be started in an agent, it does not raise an exception or return an error, and it then falsely displays the ONLINE state. An agent or manager is lead to believe the connector server is active, but all attempted connections will fail. The most likely reason for a connector server to be unable to start is a port conflict. This occurs when the port it has been instructed to use, possibly the default port, has already been taken by another object.

RMI Registry

Before starting a second RMI connector server in the same MBean server on a different port, you must launch an RMI registry for its intended port. Use the rmiregistry command line tool to do this, as explained in the JDK Tools on-line documentation (JDKinstallDir/docs/tooldocs/operatingEnv/rmiregistry.html). Failure to do so will prevent the second RMI adaptor server from starting, leading to the behavior described in the previous section.

RMI Service Names

Regardless of the port and the RMI registry, an RMI connector server created in its MBean server with a given RMI service name must be started before another RMI connector server can be created with a different service name. This applies to all RMI connector servers within the same JVM. If a second RMI connector server is created before the first is started, the RMI service name of the first will be changed to the value of the second, not the one it was given.

Tutorial

The tutorial doesn't cover all of the sample applications found in the examples directory. All of the examples include detailed README files and well-commented code. In addition, certain topics can be found elsewhere:

• The MBean registration process is covered in the JMX agent specification.

• Proxy MBeans are introduced in Getting Started with the Java Dynamic Management Kit 4.0.

• The heartbeat mechanism in protocol connectors is covered in the Javadoc for the RmiConnectorClient class and demonstrated in the HeartBeat example.

• The secure HTTP connector and the secure class loading in the m-let service are covered in their respective Javadoc pages. These components also rely on the Java Secure Socket Extension 1.0 API and the javakey tool, respectively, which are documented on Sun's Java technology web site (http://java.sun.com).

• The monitoring and timer services are covered in the JMX specification.

JDK 1.1.8 and Native Threads

When running the JDK 1.1.8 virtual machine with native threads and using an HTTP connector client, an unexpected java.lang.ClassCastException is sometimes thrown. The workaround to this problem is to deactivate the keep-alive feature of the java.net.HttpURLConnection class. You can do this by running your application with the following property definition on the command line:

$ java -Dhttp.keepAlive=false yourApplication

Green Threads

Using green threads when running with a Java virtual machine other than a production release is also a known source of errors. Avoid using this combination to minimize the risk of unexplained failures. Please refer to the JDK documentation for more information about native and green threads.