ENTMQBR-7359 - 7.10.0 Operator による認証情報シークレットの現在の処理方法を変更

Operator は、ブローカーに接続するための管理者のユーザー名とパスワードをシークレットに保存します。デフォルトのシークレット名は <custom-resource-name>-credentials-secret の形式です。シークレットは手動で作成するか、Operator による作成を許可できます。

7.10.0 より前のカスタムリソースで adminUser および adminPassword 属性が設定されている場合、Operator は手動で作成されたシークレットをこれらの属性の値で更新します。7.10.0 以降、Operator は手動で作成されたシークレットを更新しなくなりました。したがって、CR の adminUser および adminPassword 属性の値を変更する場合は、次のいずれかを行う必要があります。

ENTMQBR-7363 - 7.9 CR で AddressSettingsType の redeliveryDelayMultiplier を調整できない

redeliveryDelayMultiplier および redeliveryCollisionAvoidanceFactor 属性が 7.8.x または 7.9.x デプロイメントのメインブローカー CR で設定されている場合、7.10.x にアップグレードした後、新しい Operator は CR を調整できません。両方の属性のデータ型が 7.10.x で float から string に変更されたため、調整は失敗します。

この問題を回避するには、spec.deploymentPlan.addressSettings.addressSetting 要素から redeliveryDelayMultiplier および redeliveryCollisionAvoidanceFactor 属性を削除します。次に、brokerProperties 要素で属性を設定します。以下に例を示します。

spec:
    ...
    brokerProperties:
    - "addressSettings.#.redeliveryMultiplier=2.1"
    - "addressSettings.#.redeliveryCollisionAvoidanceFactor=1.2"

ENTMQBR-7396 - [Operator, upgrade] 7.10.1 へのアップグレードが新しい Acceptor/Connector *v1.ServiceAdmission の作成に失敗する

AMQ Broker 7.10.0 から 7.10.1 にアップグレードした後、サービスに追加された誤ったラベルと 7.10.0 の Pod セレクターがアップグレード中に削除されなかった場合は、メッセージングが機能しなくなります。アップグレード後にメッセージングが機能しない場合は、次の手順を実行してこの問題を解決してください。

ENTMQBR-7111 - Operator の 7.10 バージョンは、アップグレード中に StatefulSet を削除する傾向があります

AMQ Broker Operator 7.10.0 にアップグレードする場合、または AMQ Broker Operator 7.10.0 からアップグレードする場合、新しい Operator は調整プロセス中にデプロイメントごとに既存の StatefulSet を自動的に削除します。Operator が StatefulSet を削除すると、既存のブローカー Pod が削除され、一時的なブローカーの停止が発生します。

Operator が StatefulSet を削除する前に、次のコマンドを実行して StatefulSet を手動で削除し、実行中の Pod を孤立させることで、この問題を回避できます: oc delete statefulset <statefulset-name> --cascade=orphan

アップグレードプロセス中に StatefulSet を手動で削除すると、新しい Operator は実行中の Pod を削除せずに StatefulSet を調整できます。詳細は、Deploying AMQ Broker on OpenShift の Upgrading the Operator using OperatorHub を参照してください。

ENTMQBR-6991 - 7.10-opr-3 が 7.10-opr-2 ユーザーの PV ownerRef を修正しない

7.10.0-opr-2 をデプロイまたはアップグレードしてデプロイをスケールアップすると、新しい PV が ownerReference 属性で作成され、後でデプロイ CR を削除するとデータが失われる可能性があります。たとえば、7.10.0-opr-1 をデプロイし、7.10.0-opr-2 にアップグレードしてから、3 から 4 のブローカーインスタンスにスケーリングすると、ActiveMQArtemis CR を削除するとデータが失われる可能性があります。

この問題を回避するには、次のことができます。

ENTMQBR-6712 - テイントおよび容認 - tolerationSeconds によりデプロイメントが破損します

CR の tolerations セクションに tolerationSeconds 属性を追加する場合、Operator の調整プロセスは機能せず、ブローカー Pod は適切にスケジュールされません。この問題を回避するには、CR の tolerations セクションに tolerationSeconds 属性を追加しないでください。

ENTMQBR-6473 - スキーマ URL の変更により設定にご完成がありません

バージョン 7.9 または 7.10 インスタンスで以前のリリースからのブローカーインスタンス設定の使用を試みた場合、スキーマ URL を変更したことで互換性のない設定があると、ブローカーがクラッシュします。この問題を回避するには、Upgrading from 7.9.0 to 7.10.0 on Linux で説明されているように、関連する設定ファイルのスキーマ URL を更新します。

ENTMQBR-4813 大きなメッセージと複数の C++ サブスクライバーの使用により AsynchronousCloseException が発生します

AMQP プロトコルを使用する複数の C++ パブリッシャークライアントがサブスクライバーおよびブローカーと同じホストで実行され、パブリッシャーが大きなメッセージを送信すると、サブスクライバーの 1 つがクラッシュします。

ENTMQBR-6655 - コマンド artemis チェックキューが Could not start Jolokia agent で失敗します

実行前に、artemis check queue コマンドによりエラーメッセージ Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https communication: java.net.BindException: Address already in use が表示されていました。

ENTMQBR-6654 - requireLogin:true は、適用された新しいブローカー CR に対してのみ機能し、既存のブローカー CR に対しては機能しません。

CR で requireLogin プロパティーが true に設定されている場合、AMQ_REQUIRE_LOGIN 環境変数は既存のブローカーインスタンスのステートフルセットで更新されず、コンソール認証情報は検証されません。この問題を回避するには、既存インスタンスのステートフルセットで環境変数の値を手動で更新します。

ENTMQBR-5936 - URL がクラスター化されていないポートをターゲットにした場合に、クライアントはバックアップサーバーにフェイルオーバーしません。

クライアントが HA クラスターへの接続に使用する接続 URL に、ブローカーの static-connectors で設定されていないポートがある場合、フェイルオーバーの発生後、クライアントは以前のライブブローカーへの接続を再試行し、新しいライブブローカーへの接続を試行しません。

ENTMQBR-6728 - アップグレードパスが破損しています

この問題により、7.x チャネルにサブスクライブしている AMQ Broker 7.9 ユーザーは、AMQ Broker 7.10 に自動アップグレードできなくなります。この問題を回避するには、7.10.x チャネルにサブスクライブします。

ENTMQBR-5749- Operator Hub に表示される、サポートされていない演算子を削除する

Deploying the Operator from OperatorHub で説明されている Operators チャネルと Operator チャネルのみがサポートされています。Operator の公開に関連する技術的な理由により、他の Operator とチャネルが Operator Hub に表示されますが、無視するようにしてください。参考までに、次のリストは、表示されていても、サポートされていない演算子です。

ENTMQBR-17 - AMQ222117: クラスター接続を開始できない

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

ENTMQBR-520: 別のアドレスにバインドされたキューと同じ名前のアドレスからの受信は許可されるべきではない

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

ENTMQBR-569 - ID を OpenWire から AMQP へ変換すると、ID をバイナリーとして送信する

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

ENTMQBR-636 - perf load (mpt) の下で、ジャーナルが破損し、JavaNullPointerException が発生する

ブローカーが高負荷を管理しているときに IO 関連の問題が発生しないようにするには、JVM に十分なメモリーとヒープ領域が割り当てられていることを確認してください。ActiveMQ Artemis ドキュメントの Performance Tuning 章の Tuning the VM 項を参照してください。

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

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

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

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

ブローカーの MBean の問題:

キュー MBean の問題:

ENTMQBR-655 - [AMQP] populate-validated-user が有効になっているとメッセージを送信できない

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

ENTMQBR-897 - 宛先名の特殊文字による Openwire クライアント/プロトコルの問題

現在、AMQ OpenWire JMS クライアントは、その名前にコンマ (',')、ハッシュ ('#')、および空白を含むキューおよびアドレスにアクセスできません。

ENTMQBR-944 - [A-MQ7, Hawtio, RBAC] ユーザーは RBAC によって拒否された場合にフィードバックを取得しない

コンソールで、許可されていないユーザーが試行した操作が成功しなかったのに成功したことを示すことがあります。

ENTMQBR-1875 - [AMQ 7, ha, replicated store] バックアップブローカーがライブにならない、または ActiveMQIllegalStateException errorType=ILLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live の後にシャットダウンしているようにみえる

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

ENTMQBR-2068 - 一部のメッセージが、HA フェイルオーバー、フェイルバックのシナリオでは受信されるものの、配信されない

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

ENTMQBR-3331 - ステートフルセットコントローラーが CreateContainerError から回復できず、Operator がブロックされる

AMQ Broker Operator が設定エラーのあるカスタムリソース (CR) からステートフルセットを作成すると、ステートフルセットコントローラーは、エラーが解決されたときに更新されたステートフルセットをロールアウトできません。

たとえば、メインブローカ CR の image 属性の値にスペルミスがあると、ステートフルセットコントローラーによって作成された最初の Pod のステータスが Pending のままになります。その後、スペルミスを修正して CR の変更を適用すると、AMQ Broker Operator はステートフルセットを更新します。ただし、Kubernetes の既知の問題により、ステートフルセットコントローラーは更新されたステートフルセットをロールアウトできません。コントローラーは Pending ステータスの Pod が Ready になるまで無期限に待機するため、新しい Pod はデプロイされません。

この問題を回避するには、Pending ステータスの Pod を削除して、ステートフルセットコントローラーが新しい Pod をデプロイできるようにする必要があります。どの Pod のステータスが Pending であるかを確認するには、次のコマンドを使用します: oc get pods --field-selector=status.phase=Pending。Pod を削除するには、oc delete pod <pod name> コマンドを使用します。

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

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

ENTMQBR-4023 - AMQ Broker Operator: Pod Status の Pod 名が、実際のものとは異なる

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

ENTMQBR-4127 - AMQ Broker Operator: Operator によって生成されるルート (Route) 名が OpenShift で長すぎる可能性がある

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

この問題を回避するには、OpenShift Container Platform Web コンソールを使用してルートの名前を手動で編集します。コンソールでルートをクリックします。右上の 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 Claim (PVC) のサイズを大きくしようとすると、手動でのステップを加えずに変更は反映されません。たとえば、カスタムリソース (CR) インスタンスの storage.size プロパティーに、PVC の初期サイズを指定するとします。CR を変更して storage.size の 別の 値を指定する場合、既存のブローカーは元の PVC サイズを引き続き使用します。これは、デプロイメントをゼロブローカーに縮小してから元の数に戻した場合でも当てはまります。ただし、デプロイメントのサイズを拡大してブローカーを追加すると、新しいブローカーは新しい PVC サイズを使用します。

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