6.2. 以前の 4.x リリースでの既知の問題
このセクションでは、以前の Eclipse Vert.x 4.x リリースからの既知の問題について説明します。
6.2.1. RH-SSO が発行するトークンは、Eclipse Vert.x 4.2 に移行した後、OAuth2 検証に失敗します。
- 説明
- Red Hat Single Sign-On (RH-SSO) を認証プロバイダーとして使用する場合、Eclipse Vert.x の以前のリリースで有効であったトークンは、Eclipse Vert.x 4.2 に移行すると検証チェックに失敗します。
- 原因
- Eclipse Vert.x 4.2 では、OAuth2 認証は、Eclipse Vert.x の以前のリリースよりも厳密なセキュリティー検証を提供します。
- 回避策
-
デフォルトでは、RH-SSO はクライアント ID ではなく
accountオーディエンスでトークンを発行します。RH-SSO を認証プロバイダーとして使用している場合、Eclipse Vert.x 4.2 に移行した後、accountオーディエンスとクライアント ID を明示的に JWTOptions 設定に追加し、トークンが正常に検証されるようにする必要があります。
6.2.2. JDK 8 で vertx-oracle-client を使用するとコンパイルエラーが発生する
- 説明
-
Eclipse Vert.x 4.2 では、OpenJDK 8 を使用すると、
vertx-oracle-clientがbad class fileコンパイルエラーを出力します。 - 原因
-
Eclipse Vert.x 4.2 では、
vertx-oracle-clientは OpenJDK 11 以降で動作するように設計されています。 - 回避策
- OpenJDK 11 または OpenJDK 17 を使用します。
6.2.3. KubernetesServiceImporter() を Eclipse Vert.x Reactive Extensions (Rx) に直接登録できない
- 説明
-
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. IBM Z および IBM Power Systems では、Red Hat AMQ Streams イメージが利用できない
Red Hat AMQ Streams Operator および Kafka イメージは、IBM Z および IBM Power Systems では利用できません。イメージは利用できないため、vertx-kafka-client モジュールは IBM Z および IBM Power Systems 上の AMQ Streams と動作することが認定されていません。
6.2.5. TLS プロトコルのバージョンが一致しないため、RHEL 8 ベースのデータベースアプリケーションと RHEL 7 ベースの MySQL 5.7 データベース間の接続が失敗する
説明
RHEL 8 ベースの OpenJDK ビルダーイメージで構築されたアプリケーションコンテナーと、RHEL 7 ベースの MySQL 5.7 コンテナーイメージ上に構築されたデータベースコンテナーとの間で、OpenSSL を使用して TLS でセキュア化された接続を開くと、ランタイム時に javax.net.ssl.SSLHandshakeException によって接続に失敗します。詳細は、JIRA の問題 を参照してください。
... 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. False Connection がアプリケーションエンドポイントを呼び出す際にピアエラーメッセージによってリセットされる
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 リクエストが正しく処理され、アプリケーションは予想通りに応答します。
