IBM Support

Common status cache problems in the WebSphere Administrative Console - Part I

Technical Blog Post


Common status cache problems in the WebSphere Administrative Console - Part I



This 2-part blog is focused on some commonly occurring exceptions for the status cache problem. With this problem, the status display of an application server, node agent, or an application is shown as 'red' or 'unknown' on the WebSphere Administrative Console. However, the actual process is up running. 

In part 1, we will look at when this type of issue can occur due to one of the following areas:

  • Configuration file
  • Discovery ports with firewall
  • Operating system level

Some of these exceptions can be seen in the SystemOut, SystemError, or in FFDC log files.


Configuration file corruption

These first examples are due to corrupted configuration files:


FFDC Exception:java.lang.NullPointerException
ProbeId:202 java.lang.NullPointerException  
at$EndPtCollector.<init>( at
at java.beans.PropertyChangeSupport.firePropertyChange(
at java.beans.PropertyChangeSupport.firePropertyChange(
at java.beans.PropertyChangeSupport.firePropertyChange(
at .java:556)


FFDC Exception:java.lang.NullPointerException
java.lang.NullPointerException: getServerDiscoveryEndPoint returned null value  at at at at


Both examples are in the form of FFDC errors and a NullPointerException was thrown at the EndPoint as highlighted in bold. To resolve these types of exceptions, check the following areas:

  • Another example of configuration file to double check is the file. Make sure it is consistent with the other files for the other managed nodes under the same deployment manager configuration structure.
  • Look for other configuration files under the WAS_home/profiles/config structure to see if it is missing, and/or corrupted.


Discovery ports with firewall

The following examples are due to the discovery port being blocked or has a firewall:


FFDC ProbeId:189 ADMD0004E: The TCP socket: 72,72 cannot be opened.  Check if port is opened by remote process.   
at at


A few checkpoints for the previous exception:

  • Run a telnet test against the host name and the port number to verify the connections. For example,
  • Telnet to <CELL_DISCOVERY_ADDRESS port> on the NODE AGENT while the deployment manager is up and running.
  • Telnet to <NODE_DISCOVERY_ADDRESS port> on the DMGR while the node agent is up.
  • Verify if the host names are pingable and/or resolve to correct IP address that matches the entry in the etc/hosts file and the serverindex.xml file.


Operating system level

Another commonly seen status cache problem is due to certain  AIX level. 
Note: If you are on an AIX operating system, the status indicator of the Java virtual machines (JVM) or applications is incorrect, and there are no known errors in the SystemOut.log files, then it is possible that you have encountered a known bug.

Verify the operating system level by running: oslevel -s. If the result is either AIX 6100-08-01-1245 or AIX 7100-02-01-1245, take one of these actions:


See Part Two for more exceptions and suggestions to resolve the status cache error.


problem-problem-solution-solution (modified) credit: (cc) Some rights reserved by geralt

[{"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]