This migration guide applies to 188.8.131.52-LTS and 184.108.40.206
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.
Both Inspector based checks (
FilesystemInspector) 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 (
SharedDirectoryCheck) were introduced as replacement.
Check the appserver configuration to remove this completely obsolete section:
[...] # 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:
[...] # Sleep time between health check calls in seconds. Default is 10. #intershop.appserver.healthCheckInterval=10 [...]
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.
selfchecks.properties was introduced and should be located in
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.
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)
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
Equivalents of the constants:
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
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
The Eureka application server health check servlet (request path
/healthcheck) will additionally respond with
503 Service Unavailable for the server status
NOT_RESPONDING now, previously it was
500 Internal Server Error for
EurekaInstanceStatusMapping and all related classes need be used with
ServerInfo.Status instead of
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:
[...] # 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 [...]
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
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.
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.