Chapter 6. Known issues

6.1. Known issues in the 4.2 release

This section describes the known issues in Eclipse Vert.x 4.2.

6.1.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.1.2. JDBCClient error when searching table data by ROWID

Description
In Eclipse Vert.x 4.2, the vertx-jdbc-client with the Oracle JDBC driver throws a java.sql.SQLException when attempting to retrieve table data by using the ROWID.
Cause
In Eclipse Vert.x 4.2, the ROWID is now available as an array of bytes. In earlier releases of Eclipse Vert.x, the ROWID was available as a string type.
Workaround

Cast the row ID to an array of bytes and create a new ROWID object from this array.

For example:

ROWID rowid = new ROWID(updateResultAsyncResult.result().getKeys().getString(0).getBytes());

6.1.3. JDBCPool error when parsing ROWID

Description
In Eclipse Vert.x 4.2, the JDBC pool throws a java.lang.UnsupportedOperationException when attempting to parse the ROWID.
Cause
In Eclipse Vert.x 4.2, the ROWID cannot be parsed directly as an array of bytes. In earlier releases of Eclipse Vert.x, the ROWID could be parsed as a string type.
Workaround

Use the getValue() method to retrieve the row ID as an object, and cast this object to an array of bytes.

For example:

Row lastInsertId = rows.property(JDBCPool.GENERATED_KEYS);
ROWID rowid = new ROWID((byte[]) lastInsertId.getValue(0));

6.1.4. Unexpected results in stored procedure calls when using a PostgreSQL JDBC driver 9.0 or later

Description
In Eclipse Vert.x 4.2, the vertx-jdbc-client with a PostgreSQL JDBC driver 9.0 or later produces unexpected results in stored procedure calls.
Cause
In Eclipse Vert.x 4.2, the vertx-jdbc-client does not currently support the explicit SQL type information that modern PostgreSQL database drivers and servers require when executing callable statements.
Workaround
Use a PostgreSQL JDBC driver version earlier than 9.0.

6.1.5. 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. Known issues in earlier 4.x releases

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

6.2.1. 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.2. 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.3. 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.4. 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.