Chapter 6. Known issues

6.1. Known issues in the 4.3 release

No issues are known to affect this release.

6.2. Known issues in earlier 4.x releases

This section describes known issues from earlier Eclipse Vert.x 4.x releases.

6.2.1. Tokens issued by RH-SSO result in OAuth2 validation failures after migrating to Eclipse Vert.x 4.2

Description
If you are using Red Hat Single Sign-On (RH-SSO) as an identity provider, tokens that were valid in earlier releases of Eclipse Vert.x will fail validation checks when you migrate to Eclipse Vert.x 4.2.
Cause
In Eclipse Vert.x 4.2, OAuth2 authentication provides stricter security validation than earlier releases of Eclipse Vert.x.
Workaround
By default, RH-SSO issues tokens with the account audience rather than the client ID. If you are using RH-SSO as an identity provider, after you migrate to Eclipse Vert.x 4.2, you must explicitly add the account audience and the client ID to the JWTOptions configuration to ensure that tokens are successfully validated.

6.2.2. Compilation error when using vertx-oracle-client with JDK 8

Description
In Eclipse Vert.x 4.2, the vertx-oracle-client throws a bad class file compilation error when you use OpenJDK 8.
Cause
In Eclipse Vert.x 4.2, the vertx-oracle-client is designed to work with OpenJDK 11 or later.
Workaround
Use OpenJDK 11 or OpenJDK 17.

6.2.3. KubernetesServiceImporter() cannot be directly registered in Eclipse Vert.x Reactive Extensions (Rx)

Description
You cannot directly register KubernetesServiceImporter() with the Reactive Extensions (Rx) for Eclipse Vert.x.
Cause
Service importers do not have a generated RxJava 2 implementation.
Workaround
You must create an instance of KubernetesServiceImporter and encapsulate it with {@link io.vertx.reactivex.servicediscovery.spi.ServiceImporter} as shown in the following example:
{@link examples.RxServiceDiscoveryExamples#register(io.vertx.reactivex.servicediscovery.ServiceDiscovery)}

The following example shows how to register KubernetesServiceImporter() in Eclipse Vert.x Reactive Extensions (Rx).

ServiceDiscovery discovery = ServiceDiscovery.create(vertx);
discovery.getDelegate().registerServiceImporter(new KubernetesServiceImporter(), new JsonObject());

6.2.4. Red Hat AMQ Streams images are not available for IBM Z and IBM Power Systems

The Red Hat AMQ Streams Operator and Kafka images are not available for IBM Z and IBM Power Systems. Since the images are not available, the vertx-kafka-client module is not certified to work with AMQ Streams on IBM Z and IBM Power Systems.

6.2.5. Connection between a RHEL 8-based database application and a RHEL 7-based MySQL 5.7 database fails due to TLS protocol version mismatch

Description

Attempting to open a TLS-secured connection using OpenSSL between an application container built on a RHEL 8-based OpenJDK builder image and a database container built on a RHEL 7-based MySQL 5.7 container image results in a connection failure due to a javax.net.ssl.SSLHandshakeException at runtime: For more detail, view the issue in JIRA.

...
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
...

Cause

The issue occurs due to a difference in the latest supported TLS protocol version between RHEL 7 and RHEL 8. The TLS implementation on RHEL 7 supports TLS protocol versions 1.0 (deprecated), 1.1, and 1.2. The TLS implementation on RHEL 8 also supports TLS protocol version 1.3, which is also the default TLS version used in RHEL 8-based builder images. This discrepancy may cause a TLS protocol version mismatch between application components while negotiating a TLS handshake, which in turn causes the connection between the application and database containers to fail.

Workaround

To prevent the issue described above, manually specify a TLS protocol version that is supported on both operating system versions in your database connection string. For example:

jdbc:mysql://testdb-mysql:3306/testdb?enabledTLSProtocols=TLSv1.2

6.2.6. False Connection reset by peer error messages when calling application endpoint

Making an HTTP request on an endpoint of an Eclipse Vert.x application using either the curl tool or a Java HTTP client, produces the following error in the logs after each request:

io.vertx.core.net.impl.ConnectionBase
SEVERE: java.io.IOException: Connection reset by peer

This behavior is caused by the interaction of the Netty application framework and the HAProxy load-balancer used by OpenShift. The error occurs due to existing HTTP connections being re-used by HAProxy without closing. Even though the error message is logged, no error condition occurs. HTTP requests are handled correctly and the application responds as expected.