红帽全球峰会此内容没有您所选择的语言版本。
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.
- 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
accountaudience 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 theaccountaudience and the client ID to the JWTOptions configuration to ensure that tokens are successfully validated.
- Description
-
In Eclipse Vert.x 4.2, the
vertx-jdbc-clientwith the Oracle JDBC driver throws ajava.sql.SQLExceptionwhen attempting to retrieve table data by using theROWID. - Cause
-
In Eclipse Vert.x 4.2, the
ROWIDis now available as an array of bytes. In earlier releases of Eclipse Vert.x, theROWIDwas available as a string type. - Workaround
Cast the row ID to an array of bytes and create a new
ROWIDobject from this array.For example:
ROWID rowid = new ROWID(updateResultAsyncResult.result().getKeys().getString(0).getBytes());
ROWID rowid = new ROWID(updateResultAsyncResult.result().getKeys().getString(0).getBytes());Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.3. JDBCPool error when parsing ROWID
- Description
-
In Eclipse Vert.x 4.2, the JDBC pool throws a
java.lang.UnsupportedOperationExceptionwhen attempting to parse theROWID. - Cause
-
In Eclipse Vert.x 4.2, the
ROWIDcannot be parsed directly as an array of bytes. In earlier releases of Eclipse Vert.x, theROWIDcould 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));
Row lastInsertId = rows.property(JDBCPool.GENERATED_KEYS); ROWID rowid = new ROWID((byte[]) lastInsertId.getValue(0));Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- Description
-
In Eclipse Vert.x 4.2, the
vertx-jdbc-clientwith 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-clientdoes 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.
- Description
-
In Eclipse Vert.x 4.2, the
vertx-oracle-clientthrows abad class filecompilation error when you use OpenJDK 8. - Cause
-
In Eclipse Vert.x 4.2, the
vertx-oracle-clientis 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.
- 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
KubernetesServiceImporterand 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)}
{@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());
ServiceDiscovery discovery = ServiceDiscovery.create(vertx);
discovery.getDelegate().registerServiceImporter(new KubernetesServiceImporter(), new JsonObject());
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.
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) ...
...
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
jdbc:mysql://testdb-mysql:3306/testdb?enabledTLSProtocols=TLSv1.2
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
io.vertx.core.net.impl.ConnectionBase
SEVERE: java.io.IOException: Connection reset by peerThis 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.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}