Backporting compatibility of mpHealth-4.0 for Java EE7 and EE8 environments and introducing file-based health checks in 25.0.0.6

If you’re using Maven, include the following in your pom.xml file:

Or for Gradle, include the following in your build.gradle file:

Or if you’re using container images:

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

The MicroProfile Health 4.0 feature (mpHealth-4.0) enables a runtime for the Open Liberty server that previously supported only Jakarta EE 9 or later. In this release, the mpHealth-4.0 feature is now also supported within Java EE 7 and EE 8 environments. Also, a file-based health check mechanism is introduced as an alternative to using the /health/* REST endpoints.

The MicroProfile Health technology is most effective when the application is deployed onto a Kubernetes based environment where 'Liveness', 'Readiness' and 'Startup' probes can be used. In such a deployment scenario, applications that are deployed might be on different Java and Jakarta EE levels. This configuration can result in a mixture of mpHealth-x.x features across different servers and different Kubernetes probe configurations. The mpHealth-4.0 feature is now compatible for use with Java EE 7 and Java EE 8 alongside its existing support for Jakarta EE 9 and Jakarta EE 10 environments. This feature hence unifies Open Liberty server configurations and Kubernetes Health Check probe configurations.

In addition to the existing strategy of querying the /health/live, /health/ready, /health/started REST endpoints, this release introduces an alternative file-based health check functionality. When this function is enabled, the live, ready, and started files are created under the ${server.output.dir}/health directory. The ${server.output.dir} defaults to wlp/usr/servers/<server>. For more information, see Directory locations and properties.

The three health check files are created when the application returns an UP statuses for all three startup, liveness and readiness checks. The Open Liberty runtime will query these health checks every 100ms unless otherwise configured. This is part of the startup phase. Once these file are created the runtime proceeds to the update phase. The runtime then continues querying the liveness and readiness health checks at a user-defined interval. If the status returns UP, the last modified time of the file is updated. If a file is not updated, then it indicates that a DOWN status was returned.

This file-based functionality is only enabled if a user configures the checkInterval configuration attribute for the mpHealth configuration element or the MP_HEALTH_CHECK_INTERVAL environment variable. The check interval configuration is the value used during the update phase. If both the environment variable and the checkInterval attribute are configured, the server.xml takes precedence at run time. The configuration accepts a number followed by an optional ms or s to denote the time unit. If no time unit is specified, it defaults to seconds. Invalid values default the interval to 10 seconds.

The query interval used during the startup phase is defined with the configuration attribute startupCheckInterval. There is an accompanying environment variable with MP_HEALTH_STARTUP_CHECK_INTERVAL. Remember that this value is optional and a default of 100ms is used if no configuration is defined. Similarly, if both the server.xml and environment variable configurations are defined, the server.xml value will take precedence. The configuration accepts a number followed by an optional ms or s to denote the time unit. If no time unit is specified, it defaults to milliseconds. Invalid values default the interval to 100 milliseconds.

The following example shows the server.xml configuration:

With file-based checks, the exec command strategy can be used instead of the httpGet or gRPC strategy when configuring the Kubernetes health check probes. In this release, scripts are introduced into the Open Liberty image for these file-based health checks.

The scripts are startupHealthCheck.sh, livenessHealthCheck.sh and readinessHealthCheck.sh. For the startupHealthCheck.sh script, it is important to pass in the option -t or --timeout-seconds with a value that matches the timeoutSeconds configuration of the startup probe.

Similarly, for the livenessHealthCheck.sh and readinessHealthCheck.sh, a -p or --period-seconds option should be passed in with the value used for the periodSeconds configuration of the respective liveness and readiness probe. The liveness and readiness health check scripts check that the respective live and ready files have been updated within the past period seconds.

For best results, configure the liveness and readiness probes to at least 1.5 times greater than the checkInterval configuration.

For example, if an Open Liberty application image is configured and deployed where the checkInterval attribute is set to 10 seconds, a Kubernetes configuration similar to the following example can be used:

Notice that in the liveness and readiness probes, the periodSeconds is set to 15, or 1.5x the checkInterval.

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 25.0.0.6.

As Open Liberty features and functionality continue to grow, we continue to add new guides to openliberty.io on those topics to make their adoption as easy as possible. Checkout this new guide, Creating a multi-module application with Gradle published under the Build category. Also, all guides except the deprecated and the gradle guides are updated to use Maven wrapper.

Available through Maven, Gradle, Docker, and as a downloadable archive.