Monitor policy settings
View or change settings that control how the node agent monitors and restarts a process.
From the admin console, click...
- Servers > Server Types > WebSphere application servers > server > Server Infrastructure > Java and process management > Monitor
policy
Maximum Startup Attempts
Maximum number of times the product tries to start an application server in response to a start request. If the server cannot be started within the specified number of attempts, an error message is issued that indicates that the application server could not be started.
| Information | Value |
|---|---|
| Data type | Integer |
| Default |
3 |
Ping Interval
Specifies, in seconds the frequency of communication attempts between the parent process, such as the node agent, and the process it has created, such as an application server. Adjust this value based on your requirements for restarting failed servers. Decreasing the value detects failures sooner; increasing the value reduces the frequency of pings, reducing system overhead.
| Information | Value |
|---|---|
| Data type | Integer |
| Range | Set the value greater than or equal to 0 (zero) and less than 2147483. If we specify a value greater than 2147483, the application server acts as though we set the value to 0. When we specify a value of 0, no checking is performed. |
| Default | 60 |
(ZOS) In a z/OS environment, the Ping Interval setting for a deployment manager or a node agent is ignored. However, the Ping Interval setting for an application server is used by the node agent to control the native z/OS operating system PidWaiter monitoring function. PidWaiter monitoring is similar in functionality to the pinging function used in a distributed platform environment. Both of these monitoring functions determine whether an application server is still running. The only difference between the two monitoring functions is that PidWaiter monitoring does not send any of the TCP/IP messages that Ping Interval monitoring sends.
- If we set this property to 0, which indicates that no checking is performed, certain threads, such as PidWaiter, might terminate before the threads return their status to the initiating thread. In these situations, the deployment manager might not notifying the node agents of certain events, which could negatively impact stopServer.sh processing.
- If we set this property to a value greater than 0 but less than or equal to 5, the actual value used for the Ping Interval is 5.
(ZOS) We can also set the following two properties to considerably reduce the number of DNS lookups that might occur because of this monitoring activity:
- We can add the JVM custom property com.ibm.websphere.management.monitoring.pingInterval
for the controller for each process. The default value for this property
is 60 seconds. It is not recommended that we change this default value unless we need to minimize the number of DNS lookups that occur.
If we need to minimize the number of DNS lookups that occur, set
this property to a time interval that is more appropriate for our
system.
When this property is set for the deployment manager, it regulates how frequently the deployment manager checks to see if the node agent is still running. When it is set for the node agent, it regulates how frequently the node agent checks to see if the deployment manager is still running. When it is set for an application server, it regulates how frequently the application server checks to see if the node agent is still running.
- We can add the environment variable protocol_iiop_resolve_foreign_hostname at the cell level, and set to 0. Setting this variable to 0 disables the IIOP resolve foreign hostname function, thereby eliminating the DNS lookups this function performs.
(ZOS) Adding these two properties does not completely eliminate DNS lookups from within product processes.
Ping Timeout
When a parent process is creating a child process, such as when a process manager creates a server, the parent process pings the child process to see whether the child was created successfully. This value specifies the number of seconds that the parent process should wait (after pinging the child process) before assuming that the child process failed.
| Information | Value |
|---|---|
| Data type | Integer |
| Units | Seconds |
| Range | Set the value greater than or equal to 0 (zero) and less than 2147483647. If we specify a value greater than 2147483647, the application server acts as though we set the value to 0. |
| Default | 300 |
Automatic Restart
Specifies whether the process should restart automatically if it fails.
If we change the value specified for this field, we must restart the application server and the node agent before the new setting takes effect.
This setting does not affect what we specified for the Node Restart State setting. The two settings are mutually exclusive.
| Information | Value |
|---|---|
| Data type | Boolean |
| Default | true for the distributed and IBM i
environments
(ZOS) false for the z/OS environment |
Node Restart State
The setting only displays for the WebSphere Application Server, Network Deployment product. Specifies the desired behavior of the servers after the node completely shuts down and restarts.
If a server is already running when the node agent stops, that server is still running after the node agent restarts. If a server is stopped when the node agent restarts, whether the node agent starts the server depends on the setting for this property:
- If set to STOPPED, node agent does not start the server.
- If set to RUNNING, the node agent always starts the server.
- If set to PREVIOUS, the node agent starts the server only if the server was running when the node agent stopped.
Changes we make to the node restart state become effective after the node is synchronized. At the next NodeAgent restart (after the synch), the node restart state will be honored.
This setting does not affect what we specified for the Automatic Restart setting. The two settings are mutually exclusive.
| Information | Value |
|---|---|
| Data type | String |
| Default | STOPPED |
| Range | Valid values are STOPPED, RUNNING, or PREVIOUS. If we want the process to return to its current state after the node restarts, use PREVIOUS. |