Sun Java Enterprise System 5 Release Notes for UNIX

Monitoring Issues

This section describes the known issues in the Monitoring Console and in the Monitoring Framework. The Monitoring Framework is a shared component that is automatically installed with other components to enable monitoring.

Patches Required for Monitoring

The following patches are required to prevent certain known issues in the Monitoring Framework. These patches are normally included in other patch bundles required for Java ES or in updated versions of the Solaris operating environment. However, you should verify the existence of these patches or their replacements on any host where you will monitor a Java ES product component:

Table 1 Patches for Monitoring in the Solaris Operating Environment

Solaris Version 

Patch Number 

Solaris 9 Sparc Platform (up to and including version s9u7_06)

114344-17 

Solaris 9 i386 Platform (up to and including version s9u7_06)

114345-08 (obsoleted by: 117172-17), 118559-28 (or later) 

Solaris 10 Sparc Platform (up to and including version s10_58)

114344-17 

Solaris 10 i386 Platform (up to and including version s10_58)

114345-08 (obsoleted by: 117172-17), 118855-15 (or later) 

For the HP-UX operating system, the patches required for monitoring are included among those described in HP-UX Requirements and Issues.

Monitoring Console Interface Issues

New host certificate is not displayed for verification (6467360)

When adding a new host to be monitored, the Monitoring Console uses SSL to secure the connection, but does not show the certificate presented by the selected host. Because the Monitoring Console transmits the host's root password to the node agent, there is a vulnerability to an attacker forging the IP address of the intended host and receiving the password. The risk of this happening is very low because most node agents run on hosts already within a secure network.

Solution If your node agent hosts are not within a secure network, you should verify their authenticity before adding them as new hosts in the Monitoring Console. To verify the authenticity of a host, log in to the host and make sure you recognize its configuration and its file system. For a UNIX host, you can log in with ssh to view the certificate information.

Application Server refers to application instance (6495539, 6388513)

Objects contained in a product are referred to in Monitoring Console as an “application server.” This terminology should not be confused with Sun Java System Application Server.

Solution In the context of the Monitoring Console, an application server refers to the running instance of an installed Java ES component.

Slow response time in Monitoring Console (6490794, 6438443)

Displaying and switching pages in the Monitoring Console can take up to 30 seconds in some cases.

Solution Run the Monitoring Console on a powerful host with no other applications.

Monitoring Console does not display host or domain names (6444357, 6446325, 6496542)

Labels in the left-hand tree do not include host or domain names, only component names. This can make it difficult to identify similar components on different hosts. Similarly, when creating a monitoring rule and selecting the monitored component, instances of the same component on different hosts may be indistinguishable.

Solution Look for host identifiers in the detailed views of the monitored component. Some components include their process ID in their instance name, so you need to know the process ID of the instance on each host.

No simple way to disable monitoring of a particular component (6446505)

The Monitoring Console cannot enable or disable monitoring on a per-component basis.

Solution You must enable and disable the monitoring of a component through each component's own mechanism. For instructions, see the component–specific sections in Chapter 2, Enabling and Configuring the Monitoring Framework, in Sun Java Enterprise System 5 Monitoring Guide.

Console does not always reflect when a monitored component is stopped (6487785)

When a monitored component crashes or is stopped normally, its monitored objects may not be removed from the node agent and remain visible in the left-hand tree of the Monitoring Console. Similarly, if you stop an entire node agent, the host node may not be removed from the left-hand tree. This issue occurs intermittently.

Solution When you stop or restart a server instance, you may need to restart the node agent, the master agent and the Monitoring Console. If you stop a host and its node agent, you may need to restart the master agent and the Monitoring Console. The procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide describes how to do both.

Monitoring rules and alarms are not deleted with their host (6474032)

When a host is removed from the Monitoring Console, the monitoring rules and alarms associated with its monitored components are not deleted automatically. This allows persistency of the rules and alarm states if you add the same host again.

Solution If you do not plan on adding that host again, use the Rule dialog to find and delete all rules associated with the host. Alarms that exist when the host is removed may be acknowledged but will remain in the Monitoring Console because the monitored attribute that triggered the alarm can no longer be accessed. To avoid leaving alarms in the acknowledged state, resolve all alarm conditions in a monitored component and acknowledge the alarms in the Monitoring Console before removing the host.

Less Severe Monitoring Console Issues

The following list tracks other known issues with the Monitoring Console.

6366190

Various tables are not sorted by default

6375583

Host linked from “Objects Using This Installed Product” should not be unknown object

6388558

Using the AppServer plug-in, the “objects contained by this server” should not include children of children

6390983

Enable and disable functionality is not working correctly in the table of hosts

6396891

Caption and description fields displayed for Statistics and Settings objects but not for base objects

6495587

Selecting an object and clicking on Monitoring Rule->New should not require the user to select the object again

6405363

The names of JVM objects listed for a given host are inconsistent

6405949

CMM_Cluster objects created by Application Server are not displayed anywhere

6412408

List of observable objects in the New Rule dialog is not clear

6429231

Object and Operational Status of Portal, Web, and Application Server objects display as unknown

6388513

Enterprise Java Beans deployed in Application Server should have more descriptive names

6434184

The names of attributes in Application Server monitoring objects are impossible to use

6434241

Internal Application Server configuration changes not reflected in the Monitoring Console

Monitoring Framework Issues

Linux IPv6 loopback interface not supported (6356355)

On a Linux system, the Monitoring Framework will not work when IPv6 is enabled. As a result, the instrumentation of your monitored components on this system will not be loaded into the cacao container, and you will not see them in the Monitoring Console.

Solution There are two possible solutions:

Undeploying a monitored component from a node agent can cause a deadlock (6481273)

In the process of disabling a monitored component, it should be undeployed from its node agent, but this sometimes freezes. Specifically, the cacaoadm undeploy command never returns and monitoring is blocked in the entire node agent.

Solution Kill the process and restart the node agent, the master agent, and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.

C components have slow monitoring performance on Linux (6332884)

Components that rely on C libraries to interface with the Monitoring Framework may display more slowly in the Monitoring Console when they run in the Linux operating environment.

Solution None.

C components may have slower monitoring performance after node operations (6410218)

Components that rely on C libraries may exhibit slower monitoring performance in the Monitoring Console after other components in the same node agent are redeployed or terminated.

Solution Restart the node's Common Agent Container including the node agent, then restart the master agent and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.

C components do not communicate securely with the node agent (6405037)

Inter-process communication between components that rely on C libraries and the node agent on the same host is not secure. By default, communication uses the loopback interface, thereby reducing the security risk.

Solution None.

Java component have slow SNMP performance (6437945)

Components that rely on Java libraries to interface with the Monitoring Framework may experience performance issues when accessed through SNMP.

Solution None.

Node agent cannot discover monitored components on Solaris 9 (6504230)

Due to a bug in Solaris 9, packets addressed to an IPv4 address are not delivered to listener on an IPv6 socket. This interrupts the discovery mechanism between node agents and the components to be monitored on that host.

Solution Force the node agent's JVM to listen on IPv4 sockets with the following commands:


cacaoadm stop
oldvalue=`cacaoadm get-param java-flags --value`
cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true"

Then restart the node agent, the master agent, and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.

Unsynchronized clocks prevent adding a host to the Monitoring Console (6487357)

If the time on the node agent and master agent hosts is too far out of sync, adding that node in the Monitoring Console will fail. The error log of the master agent's Monitoring Framework will report a severe error “during JRMP connection establishment.”

Solution Set the time on either host so they are synchronous.

Documentation of private C API not supported (6463023)

Documentation for a private C API was inadvertently included in the run-time packages. The interfaces it describes are private and subject to change at any time, therefore their use is discouraged.

Solution None.

HP_UX: excessive concurrent monitoring rules causes exception (6481758)

When many monitoring rules are created in parallel in a node agent on the HP-UX operating system, thread numbers in the Java Virtual Machine (JVM) may exceed kernel parameter limits and cause an OutOfMemory exception.

Solution Download and run the HPjconfig tool, as described in the procedure To Optimize Kernel Parameters for Monitoring Framework on HP-UX in Sun Java Enterprise System 5 Monitoring Guide.