第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 を選択し、新しい値を入力します。