Red Hat AMQ Broker 7.8 のリリースノート

Red Hat AMQ 2020.Q4

AMQ Broker のリリースノート

概要

本リリースノートには、AMQ Broker 7.8 リリースに含まれる新機能、改良された機能、修正、および問題に関する最新情報が含まれています。

第1章 AMQ Broker 7.8 の長期サポート

AMQ Broker 7.8 は長期サポート(LTS)リリースバージョンとして指定されています。バグ修正とセキュリティーアドバイザリーは、少なくとも 12 カ月間、一連のマイクロリリース(7.8.1、7.8.1、7.8.1 など)で AMQ Broker 7.8 で利用できます。

つまり、新しいマイナーリリースにアップグレード しなくても、AMQ Broker の最新のバグ修正およびセキュリティーアドバイザリーを取得できます。

LTS リリースストリームに関する次の重要な点に注意してください。

  • LTS リリースストリームでは、バグ修正のみが提供されます。このストリームには新しい機能拡張は追加されません。
  • サポート対象の設定を維持するには、LTS リリースストリームの最新マイクロリリースにアップグレードする必要があります。
  • LTS バージョンは、AMQ Broker 7.8.0 GA のリリースから少なくとも 12 カ月間サポートされます。

Red Hat Enterprise Linux および OpenShift Container Platform のサポート

AMQ Broker 7.8 LTS バージョンは以下をサポートします。

  • Red Hat Enterprise Linux 6、7、8
  • OpenShift Container Platform 3.11、4.5、および 4.6

Red Hat Enterprise Linux および OpenShift Container Platform のサポートについて、以下の重要な点に留意してください。

  • AMQ Broker 7.8 は、Red Hat Enterprise Linux 6 および OpenShift Container Platform 3.11 をサポートする 最新バージョン です。
  • Red Hat は、AMQ Broker 7.8 が OpenShift Container Platform の今後のバージョンで (バージョン 4.6 以上)でサポートされていることを保証しません

AMQ Broker 7.8 LTS マイクロリリースで解決された問題の詳細は、「AMQ 7 Broker - 7.8.x Resolved Issues 」を参照してください。

第2章 改良された機能

ここでは、AMQ Broker 7.8 の機能拡張および新機能の強調表示されたセットについて説明します。リリースの機能拡張の完全リストは、「 AMQ Broker 7.8.0 Enhancements 」を参照してください。

新しいバージョンの AMQ 管理コンソール
AMQ Broker 7.8 には、新しいバージョンの AMQ 管理コンソールが含まれています。コンソールの使用に関する詳細は、『AMQ Broker の管理 』の「 AMQ 管理コンソールの使用 」を参照してください。
新しいデータベース認定
AMQ Broker 7.8 では PostgreSQL 11.5 および MySQL 8 のサポートが追加されました。異なるバージョンの AMQ Broker でサポートされるデータベースに関する詳細は、「 Red Hat AMQ 7 でサポートされる構成」 を参照してください。
アドレスおよびキューのフェデレーション
AMQ Broker 7.8 では、アドレスとキューのフェデレーションを設定できます。フェデレーションにより、ブローカーを共通のクラスターに入れることなく、ブローカー間のメッセージの転送が可能になります。たとえば、フェデレーションは、メッセージをあるクラスターから別のクラスターへ確実に送信するのに適しています。この送信は、大規模なエリアネットワーク(WAN)、クラウドインフラストラクチャーの リージョン、またはインターネット上である可能性があります。詳細は、『 AMQ Broker の設定』の「 アドレスおよびキューのフェデレーション 」を参照してください。
キューの無効化
AMQ Broker 7.8 では、ブローカー設定で定義したキューを無効にできます。たとえば、クライアントがサブスクライブできるようにキューを定義する場合がありますが、メッセージルーティングにキューを使用する準備ができていません。または、キューにメッセージフローを停止しつつも、クライアントをキューにバインドしたままにすることもできます。このような場合は、キューを無効にすることができます。詳細は、『 AMQ Broker の設定』の「 キューの無効化 」を参照してください。
キューの垂直スケーリングに関するパフォーマンスの向上
AMQ Broker 7.8 では、デプロイメントが多数のキューにスケーリングされると、ブローカーのパフォーマンスを改善するスケーラビリティーが追加されました。この改善はサポートされるすべてのプロトコルに適用されますが、大規模なデプロイメントで使用される MQTT に特に有益です。このパフォーマンスの改良点は、キュー の数が多い ブローカーデプロイメント(例: 50,000 以上)で最も顕著です。
アドレス設定を使用した Operator ベースのブローカーデプロイメントの更新
AMQ Broker 7.8 では、すでに実行されている Operator ベースのブローカーデプロイメントにアドレス設定を追加できるようになりました。ブローカーデプロイメントのカスタムリソース(CR)インスタンスにアドレス設定を含めるサポートが AMQ Broker 7.7 に追加されました。ただし、7.7 では、ブローカーデプロイメントを初めて作成する際に、アドレスの設定が必要になります。アドレス、キュー、およびアドレス設定についての詳細は、『 OpenShift での AMQ Broker のデプロイ』 の「Operator ベースのブローカーデプロイメントのアドレスおよびキューの設定 を参照してください。
ベース監査ロガーへの追加
アドレスの一時停止および再開時にベース監査ロガーがログに記録されるようになりました。ロギング の設定方法は、『 AMQ Broker の設定』の「 ロギング」を参照してください。
ブローカーアドレスのメモリー使用量率の新しいメトリクス
7.8 では、AMQ Broker の Prometheus メトリクスプラグインは、artemis_address_memory_usage_percentage という名前の新規メトリクスをエクスポートします。このメトリクスは、global-max-size パラメーターの値としてブローカーのすべてのアドレスによって使用される合計アドレスメモリーです。Prometheus メトリックスプラグインの設定方法については、『 AMQ Broker の管理 』の「 ブローカーランタイムメトリクスの監視 」を参照してください。
迂回の構成の改善
7.8 では、AMQ Management Console または管理 API を使用してライブブローカーでランタイム迂回を設定する場合、迂回は自動的にバックアップブローカーに伝播されます。これは、以前のリリースでは当てはまりませんでした。
カスタム Init コンテナーイメージの指定
7.8 の Operator の最新バージョンは、Init Container と呼ばれる特殊なコンテナーを使用してブローカー設定を生成します。デフォルトで、Operator はビルトインの Init コンテナーイメージを使用します。ただし、ビルトインの Init コンテナーによって作成される設定を修正または追加するカスタムの Init コンテナーイメージを指定することもできます。詳細は、『OpenShift での AMQ Broker のデプロイ』の「 カスタムの Init コンテナーイメージの指定 」を参照してください。
複数コンテナープラットフォームの Operator サポート

7.8 では、AMQ Broker Operator は以下のコンテナープラットフォームをサポートします。

  • OpenShift Container Platform
  • OpenShift Container Platform on IBM Z
  • OpenShift Container Platform on IBM Power Systems

IBM Power Systems での OpenShift Container Platform の Operator サポートが新たに 7.8 に追加されました。AMQ Broker 7.5 の Operator のバージョンは、IBM Z 上で OpenShift Container Platform をサポートします。

7.5 では、サポートされるプラットフォームごとに 個別の バージョンの Operator をインストールし、デプロイする必要があります。7.8 では、3 つのコンテナープラットフォームすべてをサポートする 単一の バージョンのみをインストールする必要があります。使用しているコンテナープラットフォームに基づいて、Operator はデプロイメントで使用するブローカーコンテナーイメージを自動的に選択します。

Operator の最新バージョンをインストールする方法については、『OpenShift での AMQ Broker のデプロイ』の以下のセクションを参照してください。

Operator によるブローカーコンテナーイメージの自動選択
7.8 の Operator の最新バージョンで、カスタムリソース(CR)インスタンスを使用してブローカーデプロイメントを作成する場合は、CR にブローカーコンテナーイメージ名を明示的に指定する必要がなくなりました。代わりに、CR をデプロイする際に、Operator は使用する適切なブローカーコンテナーイメージを自動的に判別します。これは、ブローカー設定を生成する Init コンテナーにも適用されます。詳細は、『OpenShift での AMQ Broker のデプロイ』の「 Operator によるコンテナーイメージの選択方法 」を参照してください。
RHEL 8 Operator

Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) という名前の Operator は、x86_64 プラットフォーム、IBM Z、および IBM Power Systems で利用できます。以下のチャンネルをサポートします。

  • 7.x - このチャンネルは、利用可能な場合に 7.9 に更新されます。
  • 7.8.x: これは LTS(Long Term Support)チャンネルです。

選択する Operator を確認するには、Red Hat Enterprise Linux Container Compatibility Matrix を参照してください。

Operator チャネル

7.8 の Operator の最新バージョンでは、以下の新規更新チャネルが Red Hat Integration - AMQ Broker Operator で利用できます。

  • 7.x - これは、現在非推奨となった current チャンネルと同等です。
  • 7.8.x: これは LTS(Long Term Support)チャンネルです。
Operator のバージョン管理
7.8 の Operator の最新バージョンで、Operator は AMQ Broker と同じバージョン管理スキームを導入するようになりました。たとえば、x86_64 プラットフォーム上の以前の Operator リリースは、OperatorHub のバージョン 0.19 でしたが、そのバージョンは 7.8.2-opr-1 に更新されます。
ドキュメントの更新
AMQ Broker ドキュメントが更新され、新しい Operator およびチャネルおよび IBM Z および IBM Power Systems のサポートに関する指示が提供されます。

その他のリソース

  • AMQ Broker 7.8 リリースの改良された一覧については、「AMQ Broker 7.8 の機能拡張 」を参照してください。

第3章 非推奨の機能

ここでは、AMQ Broker で非推奨となった機能について説明します。

Hawtio ディスパッチコンソールプラグイン
7.3 より、AMQ Broker には Hawtio ディスパッチコンソールプラグイン dispatch-hawtio-console.war が含まれなくなりました。以前のバージョンでは、ディスパッチコンソールが AMQ Interconnect の管理に使用されていました。ただし、AMQ Interconnect は独自のスタンドアロン Web コンソールを使用するようになりました。
ネットワーク pinger
7.5 以降では、ネットワークの pinging は非推奨の機能です。ネットワークの ping 送信は、復元不可能なメッセージ損失の原因となるネットワーク分離の問題からブローカークラスターを保護することができません。この機能は今後のリリースで削除されます。Red Hat は、ネットワークの ping 送信を使用する既存の AMQ Broker デプロイメントを引き続きサポートします。ただし、Red Hat では、新規デプロイメントでのネットワーク ping 送信の使用を推奨しません。高可用性を確保するためにブローカークラスターを設定する方法や、ネットワーク分離の問題を回避するために、『 AMQ Broker の設定』の「高可用性の実装」を参照してください。
OpenShift Container Platform 上の AMQ Broker のアプリケーションテンプレート
7.8 より、OpenShift Container Platform に AMQ Broker をデプロイするためのアプリケーションテンプレートの使用は非推奨になった機能になりました。この機能は今後のリリースで削除されます。Red Hat は、アプリケーションテンプレートに基づく既存のデプロイメントのサポートを続けます。ただし、Red Hat は、新規デプロイメントにアプリケーションテンプレートを使用することは推奨していません。新規デプロイメントについては、Red Hat は AMQ Broker Operator を使用することを推奨します。Operator のインストールおよびデプロイに関する詳細は、『OpenShift での AMQ Broker のデプロイ』の「AMQ Broker Operator を使用した OpenShift Container Platform での AMQ Broker のデプロイ」を参照してください。

第4章 テクノロジープレビュー

ここでは、AMQ Broker 7.8 のテクノロジープレビュー機能について説明します。

重要

テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあります。Red Hat は、実稼働環境での使用は推奨していません。詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

AMQP サーバー接続
AMQ Broker 7.8 では、ブローカーは AMQP プロトコルを使用して他のエンドポイントへの接続を開始できます。たとえば、ブローカーは他の AMQP サーバーに接続できることを意味し(必ずしも AMQ Broker のインスタンスではない)、これらのコネクションで要素を作成できます。詳細は、Apache ActiveMQ Artemis ドキュメントの「ブローカー 接続 」を参照してください。
Fuse Console でのブローカーの表示

AMQ Management Console ではなく、OpenShift の Fuse Console を使用するように Operator ベースのブローカーデプロイメントを設定できます。ブローカーデプロイメントを適切に設定した場合、Fuse Console はブローカーを検出し、専用の Artemis タブに表示されます。詳細は、『 AMQ Broker on OpenShift のデプロイ 』の「 Fuse Console でのブローカーの表示 」を参照してください。

注記

Fuse Console でブローカーを表示することは、Fuse 7.8 の テクノロジープレビュー機能です。

第5章 修正された問題

ここでは、AMQ Broker 7.8 で修正された主な問題セットについて説明します。リリースで修正された問題の完全リストは、AMQ Broker 7.8.0 の修正済み問題 および AMQ 7 Broker - 7.8.x の解決済みの問題 を参照してください。

  • ENTMQBR-1815 - 自動更新での Hawtio ビューの変更

    以前のバージョンでは、自動更新が有効な場合に Hawtio コンソールは 5 秒ごとに画面を更新していました。この動作により、ビューが Attributes タブに切り替わり、表示されていたその他のタブからフォーカスが失われました。この問題は解決されています。

  • ENTMQBR-2890 - サイズが n > 1 の CR インスタンスを作成すると、n 番目のブローカー Pod が 1 度起動し、即座に再起動する

    以前のバージョンでは、カスタムリソース(CR)インスタンスを使用して AMQ Broker Operator を使用してブローカークラスターをデプロイした場合、デプロイメントの最後のブローカー Pod(CR の size プロパティーによって決定される)が開始され、すぐに一度再起動した後、利用可能になるまで 1 回再起動していました。この問題は解決されています。デプロイメント内のブローカー Pod のいずれも使用前に再起動を実行します。

  • ENTMQBR-3059 - AMQ Broker Operator: Operator が再起動/更新後に CR 名を取得しない

    以前のバージョンでは、永続性およびメッセージ移行を使用するように設定されている 2 つ以上のブローカーのクラスター化ブローカーデプロイメントを作成した場合、メッセージ移行用にスケールダウンコントローラーをインスタンス化する際に、AMQ Broker Operator は無効な名前を生成する可能性がありました。具体的には、Operator が再起動するか、またはそのイメージがブローカーデプロイメントのスケールダウン前に更新された場合に、この問題が発生します。この状況の結果、ブローカーデプロイメントを削除し、再作成する必要がありました。この問題は解決されています。

  • ENTMQBR-3514 - AMQ Broker Operator: ブローカーがインスタンス化される前にアドレス CR が送信される場合にアドレスが作成されない

    以前のバージョンでは、Operator ベースのブローカーのデプロイメントの場合、ブローカーがインスタンス化される前にアドレスのカスタムリソース(CR)インスタンスを作成した場合、Operator はアドレスの作成に失敗しました。この問題は解決されています。

  • ENTMQBR-3578 - AMQ Broker Operator: 既存の CR インスタンスをベースラインとして使用して先に進むための Operator サポートがない

    以前のバージョンでは、AMQ Broker Operator の起動時に、プロジェクトの既存のカスタムリソース(CR)インスタンスをチェックしませんでした。この動作は、Operator を再起動する必要がある場合に(新規 Operator イメージのバージョンを適用するなど)、Operator およびブローカーデプロイメントが同期されなくなったことを意味します。この場合は、ブローカーデプロイメントを削除し、再作成する必要があります。この問題は解決されています。

  • ENTMQBR-3587 - 重大な IO エラーでシャットダウン時に通知が発生する

    以前のバージョンでは、重大な IO エラーが原因で自身をシャットダウンすると、ブローカーはディスク IO をトリガーする複数の通知を生成していました。これらの通知は、ブローカーのシャットダウンを遅らせたり、イベントが妨げたりする可能性があります。この問題は解決されています。

  • ENTMQBR-3617 - 永続性アドレスの hawtio コンソールのユーザー情報が null である

    以前のバージョンでは、コンシューマーが共有の永続サブスクリプションを作成すると、AMQ 管理コンソールはブローカーによって自動作成されたサブスクリプションキューの null として関連付けられたユーザーを表示する可能性がありました。この問題は解決されています。

  • ENTMQBR-3692 - 永続性アドレスの hawtio コンソールのユーザー情報が null である

    以前のバージョンでは、メッセージ駆動 Bean(MDB)が ActiveMQ Java Connector Architecture(JCA)リソースアダプターを使用して永続トピックサブスクリプションを作成すると、MDB はデプロイに失敗しました。この問題は解決されています。

  • ENTMQBR-3705 - LVQ と非破壊的なものでは、既存のコンシューマーにメッセージを配信しない

    以前のバージョンでは、コンシューマーが共有の永続アドレスを作成すると、AMQ 管理コンソールは関連するユーザーを null と表示する可能性がありました。この問題は解決されています。

  • ENTMQBR-3710 - キュー再開時の不正な監査メッセージ

    以前のバージョンでは、一時停止してキューを再開すると、監査ロガーに、再開イベントを別の一時停止イベントとして説明したテキストが誤って含まれていました。以下に例を示します。

    2020-07-09 11:18:00,352 [AUDIT](qtp795748540-39) AMQ601213: User amq(amq)@192.168.100.1:40858 is resuming on target resource: QueueImpl[name=helloworld, postOffice=PostOfficeImpl
    2020-07-09 11:18:00,352 [AUDIT](qtp795748540-39) AMQ601721: User amq(amq)@192.168.100.1:40858 has paused queue helloworld

    この問題は解決されています。

  • ENTMQBR-3719 - LegacyLDAPSecuritySettingPlugin により、新しいユーザーが新しく作成された宛先にアクセスできるようになる

    以前のバージョンでは、新しいパーミッションが LDAP に追加されると、LegacyLDAPSecuritySettingPlugin プラグインは、デフォルトのセキュリティー一致を変更する新しいパーミッションを使用していました。これにより、既存のユーザーの認証が破損する可能性があります。この問題は解決されています。

  • ENTMQBR-3726 - JVM プロパティー hawtio.role が空白およびハイフンを持つロールを解析しない

    以前のバージョンでは、artemis.profile ファイルが空白またはハイフンを含む hawtio.role プロパティーを定義すると、プロパティーが適切に動作しませんでした。この問題は解決されています。

  • ENTMQBR-3744 - デフォルト/ゼロ以外の consumer-window-size でグループのリバランスを有効にすると、メッセージの消費が順不同になる可能性がある

    以前のバージョンでは、接続されているコンシューマーがゼロよりも大きい consumerWindowSize の値を使用している場合(つまり、メッセージがこれらのクライアント上でバッファーに事前フェッチされている)、およびgroup-rebalance または default-group-rebalancetrueに設定して)グループのリバランスを使用するようにブローカーを設定すると、メッセージの消費が順不同になる可能性がありました。この問題は解決されています。

  • ENTMQBR-3752 - バックアップブローカーがマスターとの接続を再確立できない

    ネットワークが停止した場合に、ライブバックアップグループの両方のブローカーを同時に稼働させることができます( ネットワーク分離 または スプリットブレインと呼ばれる状況)。以前のバージョンでは、このような状況が発生すると、接続された AMQ Core Protocol JMS クライアントは誤ったブローカートポロジー情報を受け取っていました。その結果、ネットワークおよびスプリットブレインの問題が解決されると、クライアントは適切なブローカーに再接続できませんでした。この問題を回避するには、クライアントを再起動する必要があります。この問題は解決されています。

  • ENTMQBR-3782 - page-max-concurrent-io cannot be disabled

    以前は、page-max-concurrent-io の値を -1 に設定して、ページングで許容される同時読み取り数の上限を削除しませんでした。代わりに、ブローカーはデフォルト値の使用を継続し、デフォルトから変更している場合は以前に設定した値を使用します。この問題は解決されています。

  • ENTMQBR-3797 - アクティベーションに失敗すると、zombie ブローカーが発生する可能性があります。

    以前のリリースでは、ライブバックアップブローカーグループが共有ストアの高可用性を使用するように設定されている場合、ライブブローカーは再起動後に適切にアクティブにならない可能性がありましたが、ジャーナルロックの保持を継続していました。たとえば、ライブバックアップグループがネットワークファイルシステム(NFS)を使用していて、NFS が予期せず停止または削除され、ライブブローカーが再起動すると、この問題が発生する可能性があります。この状況により、クライアントを提供できず、バックアップブローカーがアクティブ化できなかったブローカーが機能しなくなっていました。この問題は解決されています。

  • ENTMQBR-3798 - JDBC XML 設定はカスタムパスワードコーデックを使用できない

    以前のバージョンでは、jdbc-password パラメーターにマスクされたパスワードとブローカー設定の password-codec パラメーターのカスタムコーディックを指定すると、ブローカーは常にデフォルトの org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec コードを使用してパスワードをデコードしていました。この問題は解決されています。

  • ENTMQBR-3812 - キューを破棄し同時にデページングする際に潜在的なデッドロック

    以前のバージョンでは、キューが破棄された(非永続コンシューマーがその接続を切断した場合など)、同時にデページングが行われると、デッドロック状態が生じる可能性がありました。この問題は解決されています。

  • ENTMQBR-3813 - キュー更新時の Null ポインター例外

    以前のバージョンでは、フィルターなしで作成されたキューを更新しようとすると、ブローカーが null ポインター例外(NPE)を表示する可能性がありました。この問題は解決されています。

  • ENTMQBR-3841 - 同時 Jolokia 操作により artemis-roles.properties または artemis-users.properties が誤って更新される可能性があります。

    以前のバージョンでは、ユーザーおよびロールまたはパーミッションを操作する複数の同時 Jolokia 操作がブローカーで実行されると、ブローカーは artemis-roles.properties または artemis-users.properties 設定ファイルの一部のデータを誤って更新したり、削除したりする可能性がありました。この問題は解決されています。

  • ENTMQBR-3880 - ページング中にワイルドカードアドレスの Destination ヘッダーが置き換えられる

    以前のバージョンでは、メッセージを保存する前に、ブローカーはメッセージの address フィールドを、ページストア名を反映するように設定していました。メッセージが、ワイルドカードアドレス式を使用してサブスクライブしたコンシューマーに対して最初にページングされている場合、他のコンシューマーが処理できなかった誤った宛先名のヘッダーが発生しました。この問題は解決されています。ブローカーが、メッセージをページストアに書き込む際にメッセージの内容を変更しなくなりました。これにより、元のターゲットアドレスはそのまま残ります。

  • ENTMQBR-4034 - 再起動後に LVQ が破損する

    以前のバージョンでは、ブローカーの再起動後に、last-value キューにある既存のメッセージは、同じ last-value キーを持つキューに送信される新しいメッセージに置き換えられませんでした。この問題は解決されています。

  • ENTMQBR-4143 - AMQ Broker Operator: CRD と Operator との間の pageSizeBytes プロパティーのタイプの不一致

    以前のリリースでは、( addressSettings.addressSetting セクションを追加することで)ブローカーデプロイメントのカスタムリソース(CR)インスタンスにアドレス設定を追加した場合に、pageSizeBytes プロパティーを含めることができませんでした。このプロパティーを含めて値を指定すると、Operator は CR の処理に失敗したか、CR を処理しましたが、ブローカーを起動する可能性があります。この問題は解決されています。

  • ENTMQBR-4144 - AMQ Broker Operator: アドレス設定 redeliveryCollisionAvoidanceFactor を指定できない

    以前のリリースでは、( addressSettings.addressSetting セクションを追加することで)ブローカーデプロイメントのカスタムリソース(CR)インスタンスにアドレス設定を追加した場合に、redeliveryCollisionAvoidanceFactor プロパティーを使用することができませんでした。このプロパティーを含めて値を指定すると、Operator は CR の処理に失敗しました。この問題は解決されています。

  • ENTMQBR-4145 - AMQ Broker Operator: アドレス設定 autoCreateJmsTopics を指定できない

    以前のリリースでは、( addressSettings.addressSetting セクションを追加することで)ブローカーデプロイメントのカスタムリソース(CR)インスタンスにアドレス設定を追加した場合に、autoCreateJmsTopics プロパティーを使用することができませんでした。このプロパティーを含めて値を指定すると、Operator は CR を処理しましたが、生成されるブローカー設定にプロパティーを含めることができませんでした。この問題は解決されています。

  • ENTMQBR-4146 - アドレス設定で default-group-rebalance-pause-dispatch プロパティーが指定されている場合にブローカーが起動しない

    以前のバージョンでは、address-setting 設定ファイルの broker.xml 要素を設定し、default-group rebalance-pause-dispatch プロパティーの値を true に設定する場合、ブローカーは起動できませんでした。

    この問題は、OpenShift Container Platform でのブローカーデプロイメントでも発生しました。具体的には、( addressSettings.addressSetting セクションを追加することで)ブローカーデプロイメントのカスタムリソース(CR)インスタンスにアドレス設定を追加し、defaultGroupRebalancePauseDispatch プロパティーの値を true に設定すると、デプロイメントのブローカーを開始できませんでした。

    この問題は解決されています。

  • ENTMQBR-4159 - AMQ Broker Operator: STOMP プロトコル用にルートが作成されていない

    本リリース以前は、アクセプターを定義して STOMP プロトコルを使用するものの、アクセプターが使用するポートを指定していない場合、Operator はアクセプターのサービスとルートを作成できませんでした。この問題は解決されています。

  • ENTMQBR-4195: AMQ ブローカー再起動後に削除されたスケジュールされたメッセージが再表示される

    本リリース以前は、管理 API を使用してスケジュールされたメッセージを削除すると、メッセージはメモリーから削除されますが、ストレージからは削除されませんでした。これにより、ブローカーを再起動する際にメッセージが再表示されました。この問題は解決されています。

  • ENTMQBR-4263 - DLQ がブローカーをシャットダウンするまでメッセージが大きくなる

    以前のバージョンでは、特定のプロトコルのメッセージがそのプロトコルに設定された大きなメッセージサイズに近く、ブローカーがメッセージをデッドレターキューに配信しようとすると、ブローカーが予期せずシャットダウンする可能性がありました。この問題は解決されています。

その他のリソース

第6章 CVE (Common Vulnerabilities and Exposures) の修正

このセクションでは、AMQ Broker 7.8 リリースで修正された Common Vulnerabilities and Exposures(CVE)について詳しく説明します。

  • ENTMQBR-3755 - CVE-2020-13932 - mqtt-client: activemq: Web コンソールダイアグラムプラグインのリモート XSS [amq-7]
  • ENTMQBR-3382 - CVE-3.10.0-957.5183 Hawtio: HTTPOnly および Secure 属性が Cookie に設定されていない [amq-7]
  • ENTMQBR-4037 - CVE-2019-12749 - DBusServer DBUS_COOKIE_SHA1 authentication bypass
  • ENTMQBR-4068 - CVE-2019-9827 - hawtio: URI の最初の /proxy/ サブストリングを介したサーバー側のリクエストフォージェリー [amq-7.7.0]
  • ENTMQBR-4158 - CVE-2020-27216 - jetty: ローカルの一時ディレクトリーのハイジャックの脆弱性 [amq-7]

第7章 既知の問題

ここでは、AMQ Broker 7.8 の既知の問題について説明します。

  • ENTMQBR-17 - AMQ222117: Unable to start cluster connection

    ブローカークラスターは、IPv6 をサポートする環境では適切に初期化できない場合があります。失敗は、ログメッセージ Can’t assign requested address によって示される SocketException が原因です。この問題を回避するには、java.net.preferIPv4Stack システムプロパティーを true に設定します。

  • ENTMQBR-463 - クラスタリング設定の属性に順序の制約がある。エラーメッセージを改善するか、

    現時点で、クラスター接続設定内の要素の順序は特定の順序で行う必要があります。回避策は、設定スキーマの順序に従うことです。

  • ENTMQBR-520 - 別のアドレスにバインドされたキューと同じ名前のアドレスから受信することはできません。

    アドレスと同じ名前を持つキューはアドレスにのみ割り当てる必要があります。既存のアドレスと同じ名前でキューを作成するが、別の名前でアドレスにバインドされるのは無効な設定です。これにより、誤ったメッセージがキューにルーティングされる可能性があります。

  • ENTMQBR-522 - シャットダウン時に一時ファイルを削除する際のウィンドウ書き込みの問題で実行されているブローカー

    Windows では、ブローカーはシャットダウン時に一時ファイルを正常にクリーンアップしません。この問題により、シャットダウンプロセスが遅くなりました。さらに、ブローカーによって削除されない一時ファイルが時間の経過と共に蓄積されます。

  • ENTMQBR-569 - ID の OpenWire から AMQP に変換すると、ID がバイナリーとして送信されます。

    A-MQ 6 OpenWire クライアントから AMQP クライアントにプロトコル間の通信時に、追加の情報はアプリケーションメッセージプロパティーにエンコードされます。これはブローカーによって内部で使用される無害な情報であり、無視できます。

  • ENTMQBR-599 - Artemis cli によるトラストストアとキーストアの定義

    --ssl-key--ssl-key-password--ssl-trust、および --ssl-trust-password パラメーターを使用してブローカーインスタンスを作成することは機能しません。この問題を回避するには、ブローカーの作成後に bootstrap.xml で対応するプロパティーを手動で設定します。

  • ENTMQBR-636 - Journal breaks, causing JavaNullPointerException causing , under perf load(mpt)

    ブローカーが負荷が大きいときに IO 関連の問題が発生しないようにするには、JVM に十分なメモリーとヒープ領域が割り当てられていることを確認します。ActiveMQ Artemis ドキュメントの「パフォーマンスチューニング」の章のセクションを参照してください。

  • ENTMQBR-648 - JMS Openwire クライアントが定義された purgeOnNoConsumer またはキューを持つキューにメッセージを送信できない filter

    A-MQ 6 JMS クライアントを使用して、purgeOnNoConsumertrue に設定されたキューを持つアドレスにメッセージを送信すると、キューのコンシューマーがない場合は失敗します。A-MQ 6 JMS クライアントを使用する場合は、purgeOnNoConsumer オプションを設定しないことを推奨します。

  • ENTMQBR-652 - 既知の amq-jon-plugin バグの一覧

    このバージョンの amq-jon-plugin には、ブローカーおよびキューの MBean に関する既知の問題があります。

    ブローカー MBean の問題:

    • 接続を閉じると java.net.SocketTimeoutException 例外がスローされます。
    • listSessions()java.lang.ClassCastException をスロー
    • アドレス設定追加で java.lang.IllegalArgumentException をスロー
    • getConnectorServices() 操作が見つかりません
    • listConsumersAsJSON() 操作が見つかりません
    • getDivertNames() 操作が見つかりません
    • ネットワークトポロジーのスローの一覧表示 IllegalArgumentException
    • アドレス設定の削除に誤ったパラメーター名がつけられました

    キュー MBean の問題:

    • expireMessage() 引数型の不一致例外をスローします
    • listDeliveringMessages() により IllegalArgumentException をスロー
    • listMessages() により java.lang.Exception をスロー
    • moveMessages() エラーメッセージ引数タイプの不一致のある IllegalArgumentException をスローします。
    • removeMessage() エラーメッセージ引数タイプの不一致のある IllegalArgumentException をスローします。
    • removeMessages() エラーのある例外が 2 つの引数を持つ操作 removeMessage を見つけられない
    • retryMessage() スローの引数タイプの不一致 IllegalArgumentException
  • ENTMQBR-655 - [AMQP] populate-validated-user が有効な場合、メッセージを送信できません。

    設定オプション populate-validated-user は AMQP プロトコルを使用して生成されたメッセージではサポートされません。

  • ENTMQBR-738 - 提供されるオフラインリポジトリーで AMQ 7 のサンプルをオフラインでビルドできない

    オフライン環境で、AMQ Broker に含まれるサンプルをビルドできません。この問題は、提供されたオフラインの Maven リポジトリーに依存関係がないために発生します。

  • ENTMQBR-897 - Openwire client/protocol issues with special characters in destination name

    現在、AMQ OpenWire JMS クライアントは、名前に次の文字が含まれるキューやアドレスにはアクセスできません。コンマ (',')、ハッシュ ('#')、より大きい ('>')、空白文字が含まれています。

  • ENTMQBR-944 - [A-MQ7, Hawtio, RBAC] User will not feedback if operation access was denied by RBAC

    コンソールには、承認されていないユーザーが試行した操作に成功したことを示すことができます。

  • ENTMQBR-1498 - HA(レプリケーション、共有ストア)の管理コンソールのダイアグラムが実際のトポロジーを反映しない

    余分なパッシブスレーブを使用してブローカークラスターを設定すると、Web コンソールのクラスターダイアグラムにこれらのパッシブスレーブは表示されません。

  • ENTMQBR-1848 - "javax.jms.JMSException: Incorrect Routing Type for queue, expecting: ANYCAST" occurs a message from a multicast queue from a multicast queue with FQQN javax.jms.Queue

    現在、Qpid JMS クライアントを使用して、複数のキューが設定されたアドレスに FQQN(完全修飾キュー名)を使用してマルチキャストキューにメッセージを送信すると、クライアントにエラーメッセージを生成し、メッセージを送信できません。この問題を回避するには、ブローカー設定を変更してエラーを解決し、クライアントのブロックを解除します。

  • ENTMQBR-1875 - [AMQ 7, ha, replicated store] バックアップブローカーが、- ActiveMQIllegalStateException errorType=ILLEGAL_STATE message=AMQ119026: Backup Server がライブと同期状態でなかった後で、ライブになるか、シャットダウンする

    バックアップブローカーがマスターブローカーとの同期を試みている間にマスターブローカーのページングディスクを削除すると、マスターブローカーは失敗します。さらに、バックアップブローカーはマスターと同期し続けるため、ライブになりません。

  • ENTMQBR-2068 - HA フェイルオーバーのシナリオ中に受信されていないメッセージがある。フェイルバックのシナリオ

    現在、OpenWire クライアントがメッセージを送信している間にブローカーがスレーブにフェイルオーバーすると、フェイルオーバーの発生時にブローカーに配信されます。この問題を回避するには、承認前にブローカーがメッセージを永続化していることを確認します。

  • ENTMQBR-2452 - Windows の AMQ 7.2.4 からアップグレードしたブローカー AMQ 7.3.0 がログに記録できない

    ブローカーインスタンスを Windows の 7.2.4 から 7.3.0 にアップグレードする予定の場合は、アップグレードプロセス時に正しいログマネージャーバージョンを指定しない限り、ロギングは機能しません。詳細は、「Windows での 7.2.x から 7.3.0 へのアップグレード」を参照してください。

  • ENTMQBR-2470 - [AMQ7, openwire,redelivery] メッセージを消費せずにコンシューマーが閉じられた場合、メッセージの増加の再配信カウンター

    ブローカーがメッセージを Openwire コンシューマーに送信し、コンシューマーがメッセージを使用する前に閉じられると、ブローカーは保留中のメッセージの再配信数を誤って増やします。この動作の数が max-delivery-attempts 設定パラメーターの値を超える場合、ブローカーはメッセージをデッドレターキュー(DLQ)に送信するか、設定に基づいてメッセージをドロップします。この問題は Core プロトコルなどの他のプロトコルには影響しません。

  • ENTMQBR-2593 - ブローカーはクロスプロトコルの消費時にメッセージ ID ヘッダーを設定しない

    Qpid JMS クライアントは、別の Qpid JMS クライアントによってメッセージが生成された場合にのみメッセージ ID が正常に取得します。メッセージが Core JMS または OpenWire クライアントによって生成された場合、Qpid JMS クライアントはメッセージ ID を読み取ることができません。

  • ENTMQBR-2678 - 分離されたマスターが再び稼働した後、クラスターに接続できない

    レプリケーション高可用性(HA)ポリシーを使用する 3 つ以上のライブバックアップグループのクラスターでは、レプリケーション接続の失敗時にライブブローカーがシャットダウンします。ただし、レプリケーション接続が復元され、元のライブブローカーが再起動すると、ブローカーはブローカークラスターに再度参加できないことがあります。元のライブブローカーがクラスターに再参加できるようにするには、まず新しいライブ(元のバックアップ)ブローカーを停止し、元のライブブローカーを再起動してから、元のバックアップブローカーを再起動します。

  • ENTMQBR-2928: Broker Operator が CR の変更から回復できず誤った状態が生じる

    カスタムリソース (CR) の更新を適用する際に AMQ Broker Operator でエラーが発生する場合、Operator は回復しません。具体的には、Operator は CR への追加の更新について予想通りに応答しなくなります。

    たとえば、メインのブローカー CR の image 属性の値に誤りがあると、ブローカー Pod は ImagePullBackOff に関連するエラーメッセージと共にデプロイに失敗します。次に、CR のスペルを修正して CR の変更を適用する場合、Operator はブローカー Pod の指定された数をデプロイしません。さらに、Operator は追加の CR の変更に対応しません。

    この問題を回避するには、最初にデプロイした CR を削除してから、それらを再デプロイする必要があります。既存の CR を削除するには、oc delete -f <CR name> などのコマンドを使用します。

  • ENTMQBR-2942 - Pod #0 が存在しない Pod に問い合わせる

    カスタムリソース(CR)インスタンスの size 属性を変更してブローカーデプロイメントをスケールダウンする場合、クラスターの最初のブローカー Pod は、シャットダウンする前に、シャットダウンしたブローカーからメッセージを移行するために起動したドレイン Pod への接続を繰り返し試行できます。この問題を回避するには、以下の手順に従います。

    1)デプロイメントを単一のブローカー Pod にスケーリングします。

    2)すべてのドレイン Pod が起動し、メッセージの移行を完了してからシャットダウンします。

    3)残りの 1 つのブローカー Pod に「不明なホスト例外」のログエントリーがある場合は、デプロイメントをゼロブローカー Pod にスケールダウンしてから 1 つに戻します。

    4)残りの 1 つのブローカー Pod が例外ベースのログエントリーを記録していないことを確認したら、デプロイメントを元のサイズに戻します。

  • ENTMQBR-3131 - マスターが強制終了されると、バックアップブローカーに対してトポロジーが正しく更新されない

    ライブ/バックアップのペアが 4 つ以上あるクラスターでライブブローカーが失敗すると、新しくされたライブブローカーを含むライブブローカーはすべて更新されたトポロジーを正しく報告します。ただし、残りのバックアップブローカーには、以下の方法で誤ったトポロジーが表示される場合があります。

    • 失敗したライブブローカーの代わりにバックアップブローカーが失敗すると、残りのバックアップブローカーはトポロジー内にこのバックアップブローカーを 2 回表示します。
    • 失敗したライブブローカーの代わりにバックアップブローカーがフェイルオーバーしない場合、残りのバックアップブローカーには、トポロジー内に失敗したライブブローカーが表示されます。

    この問題を回避するには、各バックアップブローカーの connector-ref> static-connectors 設定の最初の cluster-connection 要素で、予想されるライブブローカーを指定するようにしてください。

  • ENTMQBR-3604 - LDAP ログインモジュールのプールを有効にすると、シャットダウンがハングアップする

    LDAP プロバイダーの接続プールを有効にする場合(つまり、connectionPool 設定ファイルの true セクションで LDAPLoginModulelogin.config に設定して)、ブローカークライアントを停止する場合でも LDAP プロバイダーへの接続が永久に開かれる可能性があります。そのため、通常の方法でブローカーをシャットダウンしようとしても、ブローカーはシャットダウンしません。代わりに、SIGKILL などの Linux コマンドを使用してブローカープロセスを終了する必要があります。この状態は、ブローカーの JVM 引数にプールのタイムアウト(例: -Dcom.sun.jndi.ldap.connect.pool.timeout=30000)を指定し、ブローカーをシャットダウンする際にアクティブなクライアントがない場合でも発生します。

    この問題を回避するには、connectionTimeout 設定ファイルの LDAPLoginModule セクションで login.config プロパティーの値を設定します。接続プールが接続に対して要求されると、connectionTimeout プロパティーは、最大プールサイズがすでに到達し、プール内のすべての接続が使用されている場合にブローカーが接続を待機する最大時間を指定します。詳細は、『 AMQ Broker の設定 』の「 認証に LDAP を使用 」を参照してください。

  • ENTMQBR-3653 - メトリックスプラグインが設定されておらず、メトリクス Web コンテキストが呼び出されると NPE が発生する

    ブローカーの /metrics Web コンテキストが呼び出され、メトリックスプラグインが設定されていない場合、ブローカーは null ポインター例外を表示します。AMQ Broker の Prometheus メトリックスプラグインの設定に関する詳細は、「 Enabling the Prometheus plugin for AMQ Broker 」(オンプレミスブローカーデプロイメント)または「 Enabling the Prometheus plugin for a running broker deployment (OpenShift ブローカーデプロイメント)」を参照してください。

  • ENTMQBR-3724 - OperatorHub が AMQ Broker Operator の不適切なバリアントを表示する

    OperatorHub を使用して OpenShift Container Platform 4.5 以前に AMQ Broker Operator をデプロイする場合、OperatorHub はホストプラットフォームに適さない Operator のバリアントを表示します。これにより、誤った Operator バリアントを選択できます。特に、ホストプラットフォームに関係なく、OperatorHub は Red Hat Integration - AMQ Broker Operator(OpenShift Container Platform の Operator)および AMQ Broker Operator(IBM Z 上の OpenShift Container Platform の Operator)の両方を表示します。

    この問題を回避するには、上記のようにプラットフォームに適した Operator バリアントを選択します。または、OpenShift コマンドラインインターフェース(CLI)を使用して Operator をインストールします。

    OpenShift Container Platform 4.6 では、この問題は解決されています。OperatorHub は、お使いのホストプラットフォームに対応する Operator バリアント のみを表示します

  • ENTMQBR-3846: MQTT クライアントがブローカーの再起動時に再接続されない

    ブローカーを再起動するか、ブローカーがフェイルオーバーすると、アクティブなブローカーは、以前接続された MQTT クライアントの接続を復元しません。この問題を回避するには、MQTT クライアントを再接続するには、クライアントで subscribe() メソッドを手動で呼び出す必要があります。

  • ENTMQBR-4023: AMQ Broker Operator: Pod Status Pod の名前が現実を反映しない

    指定された OpenShift プロジェクトの Operator ベースのブローカーデプロイメントの場合、oc get pod コマンドを使用してブローカー Pod を一覧表示する場合、Pod の ordinal 値は 0 から開始します (例: amq-operator-test-broker-ss-0)。ただし、oc describe コマンドを使用して、activemqartmises カスタムリソース (oc describe activemqartemises など) から作成されたブローカー Pod のステータスを取得する場合、Pod ordinal 値は 1 で誤って開始されます (例: amq-operator-test-broker-ss-1)。この問題を回避する方法はありません。

  • ENTMQBR-4127: AMQ Broker Operator: Operator によって生成された Route 名が OpenShift で長すぎる可能性があります。

    Operator ベースのデプロイメントのブローカー Pod ごとに、Operator が AMQ Broker 管理コンソールへのアクセス用に作成する Route のデフォルト名には、カスタムリソース(CR) インスタンスの名前、OpenShift プロジェクトの名前、および OpenShift クラスターの名前が含まれます。例: my-broker-deployment-wconsj-0-svc-rte-my-openshift-project.my-openshift-domainこれらの名前の一部が長い場合には、デフォルトの Route 名が OpenShift を強制する 63 文字の制限を超えている可能性があります。この場合、OpenShift Container Platform Web コンソールで、Route には Rejected のステータスが表示されます。

    この問題を回避するには、OpenShift Container Platform Web コンソールを使用してルートの名前を手動で編集します。コンソールで Route をクリックします。右上隅の Actions ドロップダウンメニューで、Edit Route を選択します。YAML エディターで spec.host プロパティーを見つけ、値を編集します。

  • ENTMQBR-4140 - AMQ Broker Operator: storage.size が適切に指定されていないとインストールが使用できなくなる

    カスタムリソース(CR)インスタンスの storage.size プロパティーを設定し、永続ストレージのデプロイメントでブローカーに必要な Persistent Volume Claim (永続ボリューム要求、PVC) のサイズを指定する場合、この値を適切に指定しないと、Operator のインストールが使用できなくなります。たとえば、storage.size の値を 1 に設定するとします (つまり、ユニットを指定しません) 。この場合、Operator は CR を使用してブローカーデプロイメントを作成できません。さらに、CR を削除し、storage.size を正しく指定した新規バージョンをデプロイする場合でも、Operator はこの CR を使用してデプロイメントを予想通りに作成できません。

    この問題を回避するには、まず Operator を停止します。OpenShift Container Platform Web コンソールで Deployments をクリックします。AMQ Broker Operator に対応する Pod の場合は、More options メニュー (3 つの縦のドット) をクリックします。Edit Pod Count をクリックし、値を 0 に設定します。Operator Pod が停止したら、storage.size を正しく指定した状態で CR の新規バージョンを作成します。次に Operator を再起動して Edit Pod Count を再度クリックし、値を 1 に戻します。

  • ENTMQBR-4141 - AMQ Broker Operator: Persistent Volume size には、ステートフルセットの再作成後も手動で必要になる

    永続ストレージのデプロイメントでブローカーに必要な Persistent Volume Claim (永続ボリューム要求、PVC) のサイズを拡大しようとすると、追加の手順なしに変更は機能しません。たとえば、カスタムリソース (CR) インスタンスの storage.size プロパティーを設定し、PVC の初期サイズを指定する場合。CR を変更して 別の値 storage.size を指定する場合、既存のブローカーは元の PVC サイズをそのまま使用します。これは、デプロイメントをゼロブローカーにスケールダウンし、その後元の番号に戻された場合でも該当します。ただし、追加のブローカーを追加するためにデプロイメントのサイズをスケールアップする場合、新しいブローカーは新規の PVC サイズを使用します。

    この問題を回避するには、デプロイメントのすべてのブローカーが同じ PVC サイズを使用するようにするには、OpenShift Container Platform Web コンソールを使用してデプロイメントで使用される PVC サイズを拡張します。コンソールで、StoragePersistent Volume Claims をクリックします。デプロイメントをクリックします。右上隅の Actions ドロップダウンメニューで、Expand PVC を選択し、新しい値を入力します。