6.2. 之前 4.x 版本中已知的问题
这部分论述了早期 Eclipse Vert.x 4.x 版本中的已知问题。
6.2.1. 在迁移到 Eclipse Vert.x 4.2 后，RH-SSO 发布的令牌会导致 OAuth2 验证失败
- Description
- 如果您使用 Red Hat Single Sign-On (RH-SSO)作为身份提供程序，在以前的 Eclipse Vert.x 版本中有效令牌将会失败验证检查。
- 原因
- 在 Eclipse Vert.x 4.2 中，OAuth2 身份验证比之前的 Eclipse Vert.x 版本提供严格的安全验证。
- 临时解决方案
-
默认情况下，RH-SSO 使用
帐户使用者而不是客户端 ID 签发令牌。如果您将 RH-SSO 用作身份提供程序，在迁移到 Eclipse Vert.x 4.2 后，您必须明确将帐户受众和客户端 ID 添加到 JWTOptions 配置中，以确保令牌成功验证。
6.2.2. 在使用带有 JDK 8 的 vertx-oracle-client 时编译错误
- Description
-
在 Eclipse Vert.x 4.2 中，在使用 OpenJDK 8 时，
vertx-oracle-client会抛出一个错误的类文件编译错误。 - 原因
-
在 Eclipse Vert.x 4.2 中，
vertx-oracle-client的设计用于 OpenJDK 11 或更高版本。 - 临时解决方案
- 使用 OpenJDK 11 或 OpenJDK 17。
6.2.3. KubernetesServiceImporter （） 无法直接注册到 Eclipse Vert.x Reactive Extensions (Rx)
- Description
-
您不能使用 Eclipse Vert.x 的 Reactive Extensions (Rx)直接注册
KubernetesServiceImporter （）。 - 原因
- 服务导入器没有生成的 RxJava 2 实现。
- 临时解决方案
-
您必须创建一个
KubernetesServiceImporter实例，并使用{@link io.vertx.reactivex.servicediscovery.spi.ServiceImporter}封装它，如下例所示：
{@link examples.RxServiceDiscoveryExamples#register(io.vertx.reactivex.servicediscovery.ServiceDiscovery)}
以下示例演示了如何在 Eclipse Vert.x Reactive Extensions (Rx)中注册 KubernetesServiceImporter （）。
ServiceDiscovery discovery = ServiceDiscovery.create(vertx); discovery.getDelegate().registerServiceImporter(new KubernetesServiceImporter(), new JsonObject());
6.2.4. Red Hat AMQ Streams 镜像不适用于 IBM Z 和 IBM Power Systems
Red Hat AMQ Streams Operator 和 Kafka 镜像不适用于 IBM Z 和 IBM Power Systems。由于镜像不可用，vertx-kafka-client 模块没有可用于 IBM Z 和 IBM Power Systems 上的 AMQ Streams。
6.2.5. 基于 RHEL 8 的数据库应用程序和基于 RHEL 7 的 MySQL 5.7 数据库的连接会因为 TLS 协议版本不匹配而失败
Description
在基于 RHEL 8 的 OpenJDK 构建器镜像上构建的应用程序容器和基于 RHEL 7 的 MySQL 5.7 容器镜像上构建的数据库容器之间，尝试使用 OpenSSL 打开 TLS 保护的连接会导致连接失败，因为 javax.net.ssl.SSLHandshakeException 在运行时 会在以下位置查看问题 ：
... Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) ...
原因
这个问题的原因是 RHEL 7 和 RHEL 8 之间最新支持的 TLS 协议版本有不同。RHEL 7 上的 TLS 实现支持 TLS 协议版本 1.0 （已弃用）、1.1 和 1.2。RHEL 8 上的 TLS 实现还支持 TLS 协议版本 1.3，这也是基于 RHEL 8 的构建器镜像中使用的默认 TLS 版本。这种差异可能会导致应用程序组件间的 TLS 协议版本不匹配，同时强制使用 TLS 握手，进而导致应用程序和数据库容器之间的连接失败。
临时解决方案
要防止上述问题，请手动指定数据库连接字符串中两个操作系统版本支持的 TLS 协议版本。例如：
jdbc:mysql://testdb-mysql:3306/testdb?enabledTLSProtocols=TLSv1.2
6.2.6. 调用应用程序端点时，由 peer 错误消息重置的 false 连接
使用 curl 工具或 Java HTTP 客户端在 Eclipse Vert.x 应用程序的端点上发出 HTTP 请求，在每个请求后在日志中生成以下错误：
io.vertx.core.net.impl.ConnectionBase SEVERE: java.io.IOException: Connection reset by peer
此行为是由 Netty 应用框架和 OpenShift 使用的 HAProxy 负载平衡器交互造成的。此错误的原因是 HAProxy 在不关闭的情况下重新使用现有的 HTTP 连接。尽管错误消息已记录，但不会出现错误条件。HTTP 请求被正确处理，应用程序会如预期做出响应。
