Document Properties
Kbid
30B793
Last Modified
10-Nov-2023
Added to KB
17-Mar-2023
Public Access
Everyone
Status
Online
Doc Type
Guidelines
Product
ICM 7.10
Guide - 7.10.38.21 Server Health Checks

Introduction

This migration guide applies to 7.10.38.21-LTS and 7.10.40.4

The application server evaluates its healthiness in a changing environment to improve its reliability with the newly introduced server health checks during runtime. If the application server does not respond to requests in a configurable timely manner anymore or produces mostly HTTP 5xx responses, it will pause (warn severity) itself or shutdown (error severity) according to the relative amount of such error occurrences. In case of a shutdown, the JVM process will be terminated with exit code 1, which enables the node manager to restart the application server immediately. For more information about the concept of server health checks, view this page.

Migration

Inspectors

Both Inspector based checks (DatabaseInspectorFilesystemInspector) became deprecated and were removed from (un)registration/execution in EnfinityManagementImpl, as the concept of self checks was refined and allows runtime self checks which makes the thread-based Inspectors obsolete and also lowers the migration effort to ICM 11 afterwards. Equivalent runtime checks (OracleDatabaseServerPingCheckSharedDirectoryCheck) were introduced as replacement.

Check the appserver configuration to remove this completely obsolete section:

share/system/config/cluster/appserver.properties

[...]
# Sleep time between inspector calls in seconds. Default is 10.
#intershop.appserver.checkInterval=10

# Enables the database inspector, which pings the database to determine
# if a connection is possible, if set to 'true'. Default is 'false'.
#intershop.appserver.checkDB=true

# Timeout in seconds of the database inspector. The inspector waits the configured
# time for a response from the database. The value must be in a range between 1s and 30s.
# Default is 5.
#intershop.appserver.checkDB.timeout=5

# Enables the file system inspector, which pings the file system to determine
# if the file system is available, if set to 'true'. Default is 'false'.
#intershop.appserver.checkFS=true

# Timeout in seconds of the file system inspector. The inspector waits the configured
# time for a response from the file system. The value must be in a range between 1s and 30s.
# Default is 5.
#intershop.appserver.checkFS.timeout=5
[...]

This is the replacement section:

share/system/config/cluster/appserver.properties

[...]
# Sleep time between health check calls in seconds. Default is 10.
#intershop.appserver.healthCheckInterval=10
[...]

Self Checks

Self checks can use newly introduced configuring annotations @SelfCheckTaskExecutionInPhase which determine if the self check is executed during startup (previously) or startup and/or runtime (currently). The annotation is optional but recommended to use and defaults to startup if omitted.

A new selfchecks.properties was introduced and should be located in share/system/config/cluster/selfchecks.properties.

An API break of the SelfCheckTaskOutcome.Status enum was necessary to externalize the view of the self check outcome meaning and unify its status values similar to the commonly used values, e.g. in Spring Boot Health System.

Migration:

SelfCheckTaskOutcome.Status migration

Status.SKIPPED => Status.UNKNOWN
Status.OK => Status.UP
Status.WARN => Status.OUT_OF_SERVICE
Status.ERROR => Status.DOWN
Status.FAILURE => X (no equivalent, exceptions should be handled by self check now)

Server Status Constants

The ServerStatusConstants were deprecated, are no longer used, and therefore have no effects anymore on the application server logic. Instead, use ServerInfo.Status, which also comes with a convenience method fromString(String) to allow creation of such enum via a String similar to the String based ServerStatusConstants, but be aware that that method only works for the new ServerInfo.Status values.

Equivalents of the constants:

ServerInfo.Status equivalents

ServerStatusConstants.UNKNOWN => Status.UNKNOWN

ServerStatusConstants.STARTING => Status.STARTING

ServerStatusConstants.RUNNING => Status.RUNNING

ServerStatusConstants.STOPPING => Status.STOPPING

ServerStatusConstants.STOPPED => Status.STOPPED

ServerStatusConstants.TERMINATED => X (no equivalent)

X (no equivalent) => Status.MAINTENANCE

ServerStatusConstants.NOT_RESPONDING => Status.NOT_RESPONDING

Server Environment, Server Information, and ServerInfoFilterCondition

Now the server environment, server information, server info filter condition, and related classes are using the ServerInfo.Status for the server status instead of the String based ServerStatusConstants.

Eureka Server Health

The Eureka application server health check servlet (request path /healthcheck) will additionally respond with 503 Service Unavailable for the server status MAINTENANCE and NOT_RESPONDING now, previously it was 500 Internal Server Error for NOT_RESPONDING.

The EurekaInstanceStatusMapping and all related classes need be used with ServerInfo.Status instead of ServerStatusConstants.

Disable Self Checks

Disable Individual Checks

Disabling the checks is not recommended and should be only done if unavoidable for severe reasons.

To disable the certain checks, only adapting the configuration is necessary by adding the FQCN of the checks which should be disabled to the comma separated list:

share/system/config/cluster/selfchecks.properties

[...]
# Exclusion list of identifiers for self checks which should not be executed during startup
intershop.selfchecks.startup.exclusions = com.intershop.beehive.core.internal.selfcheck.ExampleCheck

# Exclusion list of identifiers for self checks which should not be executed during runtime
intershop.selfchecks.runtime.exclusions = com.intershop.beehive.core.internal.selfcheck.ExampleCheck1,com.intershop.beehive.core.internal.selfcheck.ExampleCheck2
[...]

Try-Run Runtime Checks

It is also possible to make all runtime checks produce only a log entry of the intended action instead of actually executing them, by setting the property intershop.selfchecks.tryRunEnabled to true in the selfchecks.properties. This allows the operator to gain experience with the self checks, without having the risk of automatically executed actions by the application server.

Disclaimer
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Home
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to supportadmin@intershop.de if you experience login issues,
or if you want to register as customer.