back to all blogsSee all blog posts

MicroProfile 2.1, reactive extensions, and connection pool metrics in 18.0.0.4

image of author
Laura Cowen on Dec 14, 2018
announcements , microprofile , release , reactive ,
Post available in languages:

As you’ll have come to expect from the Open Liberty project, we’ve got the latest MicroProfile version all done and dusted before the end of the year. We like to think of MicroProfile 2.1, based on Java EE 8, as “laser-focused” in its updates to the MicroProfile Open Tracing 1.2 feature. Open Tracing 1.2 enhances how you trace the flow of requests between microservices. MicroProfile 2.1 comes with a convenience feature so that you can enable all the features (existing and new) in one go, if you want.

Beyond that, Open Liberty now has reactive extensions to JAX-RS 2.1 so that you can use providers from Apache CXF and Jersey. And, on the ops side, there are connection pool metrics available from the Liberty runtime which you can now access from the /metrics endpoint that is provided by the MicroProfile Metrics feature.

Interested? Give it a whirl…​

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

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

Or for Gradle:

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

Or if you’re using Docker:

docker pull open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

What else can Open Liberty 18.0.0.4 do for your microservices? Take a look:

As we don’t have a full set of documentation implemented for Open Liberty yet, some of the items below point to the official documentation for WebSphere Liberty (WebSphere Liberty is built on Open Liberty).

MicroProfile 2.1

Open Liberty continues its support of Eclipse MicroProfile by providing the microProfile-2.1 feature. MicroProfile 2.1 was announced by the community on October 19. And, within two months, Open Liberty has a production-ready, fully-supported implementation available. Keeping to its time-boxed release mantra, MicroProfile 2.1 contains an update to a single component this time around: OpenTracing 1.2.

MicroProfile 2.1 is a convenience feature that provides the following MicroProfile features in one entry in the server.xml: jaxrs-2.1, cdi-2.0, jsonp-1.1, jsonb-1.0, mpConfig-1.3, mpFaultTolerance-1.1, mpHealth-1.0, mpJwt-1.1, mpMetrics-1.1, mpOpenAPI-1.0, mpOpenTracing-1.2, mpRestClient-1.1.

To enable all the features in MicroProfile 2.1 in your server.xml:

<featureManager>
  <feature>microProfile-2.1</feature>
</featureManager>

Learn about MicroProfile in our MicroProfile guides.

Trace the flow of requests between microservices (MicroProfile Open Tracing 1.2)

Distributed tracing enables users to see the flow of requests between microservices, including seeing which microservices have high latency and seeing the hierarchy of calls between applications and their dependent microservices.

In MicroProfile Open Tracing 1.2, you can now also:

  • Skip tracing of JAX-RS requests by specifying a regular expression that matches UriInfo.getPath()

  • Use an alternative format for span names. The new format is <http method>:/@Path value of endpoint’s class>/<@Path value of endpoint’s method>. For example, GET:/inventory/list

Enable the two new functions by defining two keys using MicroProfile Config (e.g. in server.xml or bootstrap.properties):

  • mp.opentracing.server.skip-pattern

  • mp.opentracing.server.operation-name-provider

See also:

New connection pool metrics (Monitor 1.0 with MicroProfile Metrics 1.1 updates)

Liberty metrics are provided in two ways. The Monitor 1.0 feature provides JMX MXBeans which can be monitored to gather metrics about Liberty components. As an alternative, the MicroProfile Metrics 1.1 feature provides a /metrics endpoint which can be monitored to gather Liberty component metrics. Choosing between monitor-1.0 and mpMetrics-1.1 can largely be done based on which technology (JMX or HTTP) your tools use to gather metrics.

In 18.0.0.4, there are new connectionPool metrics added to both Monitor 1.0 and MicroProfile Metrics 1.1. For connection pools, we’ve introduced metrics for Total Wait time, Total Queued Requests Count, Total In Use Time, and Total Used Connections. JAX-WS metrics, formerly only available from monitor-1.0, are now also exposed by the mpMetrics-1.1 /metrics endpoint.

The existing connection pool InUseTime and WaitTime metrics, available for Monitor 1.0, showed average values calculated based on all samples since the time the metrics were created. Over time that meant these metrics would plateau to an average value and stop changing. That isn’t useful if you want to know what the average wait time was for getting connections over the last 15 minutes. The new metrics track the total amount of use/wait time (since the metric was created) and the total count of requests (since the metric was created) separately. These new metrics will work particularly well with tools like Prometheus which can show the rate of change of one metric divided by rate of change of another. With these new metrics Prometheus could show you what the use/wait time average was over the last 5 minutes, or yesterday between 2pm and 4pm.

JAX-WS metrics can now be accessed by tools that gather metrics from the /metrics endpoint.

To make Monitor 1.0 metrics available at the /metrics endpoint:

  1. Set up MicroProfile Metrics 1.1.

  2. Add monitor-1.0 to your server.xml:

    <featureManager>
  <feature>mpMetrics-1.1</feature>
  <feature>monitor-1.0</feature>
</featureManager>

  3. To view JAX-WS and the new connection pool metrics, ensure that your application makes use of JAX-WS web services and any data source (e.g. JDBC), and make sure the following features are included in the server.xml as follows:

    <featureManager>
  . . .
  <feature>mpMetrics-1.1</feature>
  <feature>monitor-1.0</feature>
  <feature>jdbc-4.0</feature>
  <feature>jaxws-2.2</feature>
  . . .
</featureManager>

Learn about MicroProfile Metrics in the Providing metrics from a microservice guide.

For more info:

Reactive extensions to JAX-RS 2.1

JAX-RS 2.1 introduced the reactive client, but the spec only requires vendors to implement it using Java 8’s CompletionStage API. Other reactive frameworks can integrate with the reactive client, but that is optional in the spec. With Liberty 18.0.0.4, it is now possible to use these extensions. We’ve tested with RxJava 1 and 2 using providers from Apache CXF and Jersey, and we plan to test more. If there is a particular reactive technology that you would like to use, and it has a JAX-RS RxInvokerProvider implementation, please let us know!

To find out what else the the Open Liberty REST team has done this year, take a look at Andy’s recent blog post.

Package server TAR files for simpler Dockerfiles

Liberty’s server package tool now supports packaging to .tar and .tar.gz files. The package tool has long supported generating to .zip and .jar files, but, until now, the most common packaging format on Linux hasn’t been an option.

So why now? It all relates to making Liberty work better with Docker. Docker’s ADD command has built-in support for extracting .tar files. Adding a server package to your Dockerfile is now really simple.

Instead of doing this:

RUN apt-get update && \
apt-get install unzip && \
unzip /tmp/defaultServer.zip /opt/ol/ && \
apt-get remove -y unzip && \
rm -rf /var/lib/apt/lists/*

you can now simply write:

   FROM open-liberty
   ADD defaultServer.tar.gz /opt/ol/

Ability to pass application arguments through server command line

You can now specify Liberty server variables when you launch the Liberty server. These variables can be used in server.xml, MicroProfile config, and are also made available to SpringBoot apps via their main method. When running the Liberty server start command, use --<variable>=<value> syntax and separate the variables from the server configuration using -- for example:

server start defaultServer -- --myArgument=value

when packaging Liberty as an executable JAR file the -- is not necessary so you can do:

java -jar defaultServer.jar --myArgument=value

Specify a root directory when packaging servers

When packaging a server from the command line using the server package command, you can now optionally specify the Open Liberty root directory in the archive. This enables you to extract the archive into your directory structure and not have to manually modify it to fit your naming scheme.

For example, to obtain an archive called myServerPackage.zip which contains the archived Open Liberty server with the folder structure /MyRoot/…​ instead of /wlp/…​, run the command:

server package myServer --archive=myServerPackage.zip --server-root=MyRoot

For more info, see: server package

Bug fix: Remove acceptLicence requirement when installing Liberty features

An historic requirement no longer necessary. All Open Liberty features are licensed under the EPL like the runtime.

Ready to give it a try?

Get the Maven or Gradle coordinates (and other download options) from the top of this post.

Ask a question on Stack Overflow