test

Java Dynamic Management Kit 4.2 Installation Guide and Release Notes

Known Limitations

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

Heartbeat Cross-Compatibility

When a manager application running with version 4.1 of the product is communicating with agents running version 4.2, the heartbeat mechanism will cause an exception the second time the connect method is called. This behavior occurs in all connectors: RMI, HTTP, and HTTPS.

If you do not need the heartbeat functionality, you may avoid this limtation by disabling the heartbeat. If you do so, you must disable the heartbeat before the first connection, by setting the heartbeat period to 0 (zero). Once you have disabled the heartbeat, your connector client may connect and disconnect as many times as you wish.

If you would like to use the heartbeat functionality in this configuration, you should not establish more than one connection per connector client. The heartbeat mechanism is fully functional during the first connection. If you need establish a second connection after the first, you should disconnect and instantiate a new connector client for the second connection.

SNMPv2 Protocol

Report PDUs are not supported in the Java Dynamic Management Kit 4.2 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 managers or between managers, respectively.

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.

HTTPS Heartbeat on Windows NT

The HTTPS connector client on the Windows NT platform may signal a false CONNECTION_REESTABLISHED notification, when its connector server is stopped. Thereafter, the correct CONNECTION_LOST notification is received. As this is due to timing issues, it is best to use a heartbeat period of five seconds or longer.

RMI Registry

Before starting a second RMI adaptor server in the same agent, 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 online documentation (JDKinstallDir/docs/tooldocs/operatingEnv/rmiregistry.html). Failure to do so will prevent the second RMI adaptor server from starting.

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:

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.

M-Let with JDK 1.3 Software

When using the m-let service with the JDK 1.3 software, in particular when calling the method getMBeansFromURL(java.lang.String url) or getMBeansFromURL(java.net.URL url), a javax.management.ServiceNotFoundException is raised. This occurs because the JDK 1.3 APIs send HTTP/1.1 client requests and some HTTP server versions will reject all client requests that are not HTTP/1.0 or HTTP/0.9. Therefore, you need to ensure that your HTTP server accepts HTTP/1.1 client requests.

SnmpVarBind Status

In prior releases of the Java Dynamic Management Kit, the SnmpVarBind status was handed differently, depending upon whether you were using SNMP v1 or SNMP v2. This is no longer the case with the Java Dynamic Management Kit 4.2. The SnmpVarBind status handling has been modified to allow the user to perform status checking in the same way for both SNMP v1 and SNMP v2, although it may impact the Java code if you are using SNMP v2.

Now, regardless of the SNMP version you use to send a request, theSnmpVarBind status, as given by the getValueStatus method, always reflects the way that the SNMP request was sent (i.e. whether you used SNMP v1 or SNMP v2). Therefore, you may compare it with the constants stValueOk, stValueEndOfMibView, stValueNoSuchInstance, stValueNoSuchObject, or stValueUnspecified, which are defined in the SnmpVarBind class.