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 theaccount
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 ajava.sql.SQLException
when attempting to retrieve table data by using theROWID
. - Cause
-
In Eclipse Vert.x 4.2, the
ROWID
is now available as an array of bytes. In earlier releases of Eclipse Vert.x, theROWID
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 theROWID
. - 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, theROWID
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 abad 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.