back to all blogsSee all blog posts

Faster startup for Spring Boot 3.x applications and more in

image of author
David Mueller on Jun 18, 2024
Post available in languages:

The release introduces the Coordinated Restore at Checkpoint feature, which improves startup times for Spring Boot 3.x applications with Liberty InstantOn. This release also includes InstantOn support for applications that use distributed HTTP session caching and IBM MQ messaging.

In Open Liberty

View the list of fixed bugs in

Develop and run your apps using

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


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

buildscript {
    repositories {
    dependencies {
        classpath ''
apply plugin: 'liberty'

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.

Ask a question on Stack Overflow

Faster startup of Spring Boot apps (Spring Boot 3.0 InstantOn with CRaC)

Open Liberty InstantOn provides fast startup times for MicroProfile and Jakarta EE applications. With InstantOn, your applications can start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. InstantOn uses the Checkpoint/Restore In Userspace (CRIU) feature of the Linux kernel to take a checkpoint of the JVM that can be restored later.

The Spring Framework (version 6.1+) includes support for Coordinated Restore at Checkpoint (CRaC), which also uses CRIU to provide Checkpoint and Restore for Java applications. Spring Boot version 3.2+ uses Spring Framework version 6.1+, which enables Spring Boot applications to also use CRaC to achieve rapid startup times.

The Open Liberty springBoot-3.0 feature allows Spring Boot 3.x-based applications to be deployed with Open Liberty. And now, with the new Open Liberty Coordinated Restore at Checkpoint (crac-1.4) feature, a Spring Boot 3.2+ application can be deployed with Liberty InstantOn and achieve rapid startup times.

To use the CRaC 1.4 functionality with the springBoot-3.0 feature, you must be running with Java 17 or higher and enable the crac-1.4 feature in your server.xml file. Additionally, if your application uses Servlet, it needs to use the servlet-6.0 feature. Configure these features in the server.xml file, similar to the following example:


With these features enabled, you can containerize your Spring Boot 3.2+ application with Liberty InstantOn support by following the Liberty InstantOn documentation and the Liberty recommendations for containerizing Spring Boot applications in the Liberty Spring Boot guide.

For more information and an example Spring Boot application that uses the Liberty InstantOn crac-1.4 feature, see the How to containerize your Spring Boot application for rapid startup blog post.

You can also use the crac-1.4 feature with other applications, such as applications that use Jakarta EE or MicroProfile. Such applications can register resources with CRaC to get notifications for checkpoint and restore. These notifications help applications to prepare for a checkpoint and to perform necessary actions when the application is restored. For more information on the org.crac APIs, see the org.crac Javadoc.

InstantOn support for Jakarta Messaging with IBM® MQ

The release introduces InstantOn support for the Jakarta Messaging, Jakarta Connectors, and Jakarta Enterprise Beans Message-Driven Beans (MDB) features. InstantOn now provides blazing fast startup times for applications that use resource adapters to access external EIS resources, including applications that use the Jakarta Messaging API to access external messaging systems like IBM® MQ. These messaging client applications can also manage message delivery to endpoints with message-driven bean listeners.

For Jakarta EE 10 messaging applications that provide message-driven bean endpoints and access messaging resources that are provided by IBM® MQ, enable the messaging-3.1 and mdb-4.0 features and specify the path to the IBM® MQ resource adapter. The feature configuration automatically includes the connectors-2.1 feature, which supports the resourceAdapter configuration element.


<resourceAdapter id="mqJms" location="${server.config.dir}/wmq.jakarta.jmsra-"/>
Developer tip

You can use the MQ in Container image IBM® MQ server that provides the following resources: queue manager QM1 listening on port 1414, queue DEV.QUEUE.1, and channel DEV.APP.SVRCONN. These resources can support a simple point-to-point messaging scenario and are named within the messaging feature configuration elements that are shown in the following example.

InstantOn can dynamically update the messaging and connectors configuration elements to enable connections to external resources that are made available in any environment where a server is restored from checkpoint.

For example, the following messaging configuration declares Liberty variables to specify the hostname and IP port of the system that hosts the IBM® MQ queue manager. Define these variables in the restore environment of the server. When the server restores, the connection factory and message endpoint activation configurations will update to the environment-specific hostname and port values that enable Open Liberty to connect to the IBM® MQ queue manager.

   <jmsQueue id="jms/queue1" jndiName="jms/queue1">
      <properties.mqJms  baseQueueName="DEV.QUEUE.1"  baseQueueManagerName="QM1"/>

   <variable name="MQ_PORT" value="1414"/>
   <variable name="MQ_HOSTNAME" value="localhost"/>

   <jmsQueueConnectionFactory jndiName="jms/qcf1" connectionManagerRef="ConMgr7">
      <properties.mqJms  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>

   <jmsConnectionFactory jndiName="jms/cf1" connectionManagerRef="ConMgr1">
      <properties.mqJms  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>
    <connectionManager id="ConMgr1" maxPoolSize="10"/>

   <jmsActivationSpec id="myapp/mymdb/FVTMessageDrivenBean">
      <properties.mqJms  destinationRef="jms/queue1"  destinationType="jakarta.jms.Queue"
            transportType="CLIENT"  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>

Stay tuned for upcoming announcements regarding InstantOn support for Jakarta features.

InstantOn support for distributed HTTP session caching

The release also provides InstantOn support for the JCache Session Persistence feature. This feature uses a JCache provider to create a distributed in-memory cache. Distributed session caching is achieved when the server is connected to at least one other server to form a cluster. Open Liberty servers can behave in the following ways in a cluster.

  • Client-server model: An Open Liberty server can act as the JCache client and connect to a dedicated JCache server.

  • Peer-to-Peer model: An Open Liberty server can connect with other Open Liberty servers that are also running with the JCache Session Persistence feature and configured to be part of the same cluster.

To enable JCache Session Persistence, the sessionCache-1.0 feature must be enabled in your server.xml file:


You can configure the client/server model in the server.xml file, similar to the following example.

<library id="InfinispanLib">
    <fileset dir="${shared.resource.dir}/infinispan" includes="*.jar"/>
<httpSessionCache cacheManagerRef="CacheManager"/>
<cacheManager id="CacheManager">
    <cachingProvider jCacheLibraryRef="InfinispanLib" />

You can configure the peer-to-peer model in the server.xml file, similar to the following example.

<library id="JCacheLib">
    <file name="${shared.resource.dir}/hazelcast/hazelcast.jar"/>

<httpSessionCache cacheManagerRef="CacheManager"/>

<cacheManager id="CacheManager" >
    <cachingProvider jCacheLibraryRef="JCacheLib" />

Note: To provide InstantOn support for the peer-to-peer model by using Infinispan as a JCache Provider, you must use Infinispan 12 or later. You must also enable MicroProfile Reactive Streams 3.0 or later and MicroProfile Metrics 4.0 or later in the server.xml file, in addition to the JCache Session Persistence feature.

The environment can provide vendor-specific JCache configuration properties when the server is restored from the checkpoint. The following configuration uses server list, username, and password values as variables defined in the restore environment.

<httpSessionCache libraryRef="InfinispanLib">
    <properties infinispan.client.hotrod.server_list="${INF_SERVERLIST}"/>
    <properties infinispan.client.hotrod.auth_username="${INF_USERNAME}"/>
    <properties infinispan.client.hotrod.auth_password="${INF_PASSWORD}"/>
    <properties infinispan.client.hotrod.auth_realm="default"/>
    <properties infinispan.client.hotrod.sasl_mechanism="PLAIN"/>

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes



XML External Entity (XXE) injection -

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Get Open Liberty now