back to all blogsSee all blog posts

InstantOn startup and Liberty Tools in Open Liberty 23.0.0.6

image of author
Michal Broz on Jun 27, 2023
announcements , microprofile , release , maven , docker , gradle , jakarta-ee , developer-experience , performance-enhancements , devops ,
Post available in languages: 日本語 ,

Open Liberty 23.0.0.6 adds the exciting Liberty InstantOn capability! With InstantOn, your applications can start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. We are also excited to announce the release of the Liberty Tools v23.0.6, which makes Liberty development even faster by providing various development comforts like hover-over, quick fix, and diagnostic support. This release also provides many significant bug fixes, including one that addresses a CVE in the MicroProfile GraphQL features.

In Open Liberty 23.0.0.6:

Check out previous Open Liberty GA release blog posts.

Join our live webinars with the Open Liberty development team. Get updates and answers to your questions. The webinars are scheduled to accommodate different timezones and are similar in content. Register here to join live or to access the recordings later:

Run your apps using 23.0.0.6

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.6</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.6,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Rapid startup with Liberty InstantOn

Performance is one of the core focuses and differentiators of the Liberty runtime. As far back as 2019, Liberty was able to start up in ~1sec. Since then, Liberty has continued to pursue even faster startup, and this focus on performance has resulted in the InstantOn capability. Liberty InstantOn enables your applications to start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features.

To reduce the cost of running applications in the cloud, it is ideal to run the application only when it is needed. Unneeded application instances should be stopped. As soon as activity increases again, a new application instance needs to start up quickly and respond to incoming requests efficiently. This is known as scale-to-zero. Applications that take multiple seconds to start cannot scale-to-zero without introducing high latency for the application user.

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. With InstantOn, the application is developed as normal, and then InstantOn makes a checkpoint of the application process when the application container image is built. When the application is restored, it runs in the same JVM, which provides complete parity between development and production. Because the checkpoint process takes only seconds, your CI/CD process is barely affected. The restoration of the image takes only milliseconds, allowing your applications to quickly scale up and down, which provides cost benefits without any negative impacts on the end users.

InstantOn supports Jakarta EE Web Profile versions 8.0 and later, MicroProfile versions 4.1 and later, as well as several other Liberty features. For more information, see the How to package your cloud-native Java application for rapid startup blog post and the Faster startup with InstantOn documentation.

Liberty Tools

The Liberty Tools v23.0.6 are now available! Some highlights include diagnostic and hover support for MicroProfile (3.x and later) and Jakarta EE Web Profile (9.x and later) APIs, as well as various Liberty config files. The Liberty Tools are available for Visual Studio Code, IntelliJ IDEA, and Eclipse IDE.

To get started with the Liberty Tools, you can obtain the link to install the tools for your favorite IDE from the Get started with Open Liberty page.

For more information, see the Develop with Liberty Tools documentation.

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2023-28867

7.5

Denial of service

17.0.0.3 - 23.0.0.5

Affects the mpGraphQL-1.0 and mpGraphQL-2.0 features

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

Notable bugs fixed in this release

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 23.0.0.6.

  • JSF Container’s Application.getWrapped returns null

    The JSF Container features return null when javax.faces.application.Application.getWrapped method is called.

    This issue has been resolved and the correct wrapped object is returned.

  • transport close timing issue when streams are closing and a close/goaway frame comes in

    Since Http/2 and webSocket are full duplex connections, multiple threads might be working at the same time on the same connection. A timing window existed where one thread is closing down the connection, gets interrupted, and another thread closes the connection. Then the first thread wakes back up to resources that have already been freed.

    The error may produce an exception similar to the following:

    java.io.IOException: Request not read yet
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.finishResponseMessage(HttpInboundServiceContextImpl.java:907)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.finishResponseMessage(HttpInboundServiceContextImpl.java:989)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.close(HttpInboundLink.java:678)
> at com.ibm.wsspi.channelfw.base.InboundApplicationLink.close(InboundApplicationLink.java:105)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.close(HttpDispatcherLink.java:244)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.finish(HttpDispatcherLink.java:1022)
> at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:293)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:1159)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:428)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:387)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:566)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:500)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:360)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:327)
> at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:167)
> at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:75)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:958)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1047)
> at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:238)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)

    This issue has been resolved by ensuring a thread doesn’t attempt to close a connection that has already been closed by another thread.

  • Posting Form-Data with the new Jakarta EE 10 Multipart Support fails

    When posting multipart/form-data to a REST endpoint using the @FormParam annotation for an EntityPart or InputStream parameter, the request fails with a 400 Bad Request response, and the following exception is logged:

    jakarta.ws.rs.BadRequestException: RESTEASY003320: Failed processing arguments of public java.lang.String com.demo.rest.TestResource.upload(java.lang.String,jakarta.ws.rs.core.EntityPart) throws java.io.IOException
at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:120)
Caused by: java.lang.UnsupportedOperationException: SRVE8020E: Servlet does not accept multipart requests
at com.ibm.ws.webcontainer.srt.SRTServletRequest.prepareMultipart(SRTServletRequest.java:3838)

    During deployment, when using an EntityPart parameter, the following warning is logged:

    SROAP04005: Could not find schema class in index: jakarta.ws.rs.core.EntityPart

    This issue has been resolved and the @FormParam annotation can now be used with EntityParts.

  • server version command ignores JAVA_HOME set in server’s server.env

    The server version <serverName> command ignores the JAVA_HOME variable that is set in the server’s server.env file. Instead it prints out the Java version info of the Java installation set by JAVA_HOME variable in shell environment (bash).

    This issue has been resolved and the server version command now correctly identifies the Java version as specified in the server.env file.

Get Open Liberty 23.0.0.6 now

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