Red Hat AMQ Broker 7.10 发行注记

ENTMQBR-7359 - 使用 7.10.0 Operator 开始当前处理凭证 secret

Operator 在 secret 中存储用于连接代理的管理员用户名和密码。默认 secret 名称采用 < custom-resource-name> -credentials-secret 的形式。您可以手动创建 secret，或允许 Operator 创建 secret。

如果在 7.10.0 之前在自定义资源中配置 adminUser 和 adminPassword 属性，Operator 会使用这些属性的值更新手动创建的 secret。从 7.10.0 开始，Operator 不再更新手动创建的 secret。因此，如果更改了 CR 中的 adminUser 和 adminPassword 属性的值，您必须：

ENTMQBR-7363 - 从 7.9 CR 的 AddressSettingsType 中的 redeliveryDelayMultiplier 无法被协调

如果 redeliveryDelayMultiplier 和 redeliveryCollisionAvoidanceFactor 属性在 7.8.x 或 7.9.x 部署中的主代理 CR 中配置，新的 Operator 在升级到 7.10.x 后无法协调任何 CR。协调失败，因为两个属性的数据类型从 float 改为 7.10.x 中的字符串。

您可以通过删除 spec.deploymentPlan.addressSettings.addressSetting 元素的 redeliveryDelayMultiplier 和 redeliveryCollisionAvoidanceFactor 属性来解决这个问题。然后，在 brokerProperties 元素中配置属性。例如：

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

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 - 7.10 版本会在升级过程中删除 StatefulSet

如果您要升级到 AMQ Broker Operator 7.10.0，新 Operator 会在协调过程中自动删除每个部署的现有 StatefulSet。当 Operator 删除 StatefulSet 时，现有代理 pod 会被删除，这会导致临时代理中断。

您可以运行以下命令来手动删除 StatefulSet 并孤立运行的 pod，从而删除 StatefulSet: oc delete statefulset < statefulset-name& gt; --cascade=orphan

在升级过程中手动删除 StatefulSet 可让新 Operator 协调 StatefulSet，而不删除正在运行的 pod。如需更多信息，请参阅在 OpenShift 上部署 AMQ Broker 中使用 OperatorHub 升级 Operator。

ENTMQBR-6991 - 7.10-opr-3 不会为 7.10-opr-2 用户修复 PV ownerRef

如果您部署或升级到 7.10.0-opr-2 并扩展部署，则会使用 ownerReference 属性创建新的 PV，如果稍后删除部署 CR，则会导致数据丢失。例如，如果您部署 7.10.0-opr-1，升级到 7.10.0-opr-2，然后从 3 扩展到 4 代理实例，如果您删除 ActiveMQArtemis CR，则可能会丢失数据。

要解决这个问题，您可以：

ENTMQBR-6712 - Taints 和 Tolerations - "tolerationSeconds" 会破坏部署

如果您在 CR 的 tolerations 部分添加 tolerationSeconds 属性，Operator 协调过程无法正常工作，且代理 pod 不会被正确调度。要临时解决这个问题，在 CR 的 tolerations 部分不要在 tolerationSeconds 属性中添加 tolerationSeconds 属性。

ENTMQBR-6473 - 因为 schema URL 的变化而兼容配置

当您尝试使用带有版本 7.9 或 7.10 实例的之前的版本中的代理实例配置时，schema URL 改变会导致代理崩溃。要临时解决这个问题，在从 7.9.0 升级到 7.10.0 时，将相关配置文件中的 schema URL 更新至 7.10.0。

ENTMQBR-4813 AsynchronousCloseException，带大型消息和多个 C++ 订阅者

如果多个使用 AMQP 协议的 C++ publisher 客户端与订阅者和代理一样运行，且发布者会发送一个大型消息，订阅者崩溃。

ENTMQBR-6655 - 命令 artemis 检查队列失败，并显示 "Could not start Jolokia agent"

在运行之前，artemis check queue 命令显示以下错误消息： Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https 通信： 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 中配置的端口，在故障切换发生后，客户端会重试到之前 live 代理的连接，且不会尝试连接到新的实时代理。

ENTMQBR-6728 - 升级路径无法正常工作

这个问题可防止升级到 7.x 频道的 AMQ Broker 7.9 用户自动升级到 AMQ Broker 7.10。要解决这个问题，请订阅 7.10.x 频道。

ENTMQBR-5749 - 删除 OperatorHub 中可见的、不支持的 operator

仅支持 通过 OperatorHub 部署 Operator 中的 Operator 和 Operator 频道。对于与 Operator 发布相关的技术原因，其他 Operator 和频道在 OperatorHub 中可见，并应忽略。为了参考，以下列表显示了哪些 Operator 可见，但不被支持：

ENTMQBR-17 - AMQ222117: Unable to start cluster connection

在支持 IPv6 的环境中，代理集群可能无法正确初始化。故障是由于 SocketException 所指示 的，它通过日志消息不分配请求的地址。要临时解决这个问题，请将 java.net.preferIPv4Stack 系统属性设置为 true。

ENTMQBR-520 - 不允许与绑定到另一个地址的队列相同的地址接收

名称与地址相同的队列必须仅被分配到地址。创建名称与现有地址相同的队列，但绑定到具有不同名称的地址是一个无效的配置。这样做可能会导致错误消息路由到队列。

ENTMQBR-569 - 将 OpenWire 的 ID 转换为 AMQP 会导致将 ID 发送为二进制

当将跨协议从 A-MQ 6 OpenWire 客户端与 AMQP 客户端通信时，会在应用程序消息属性中对额外的信息进行编码。这是代理在内部使用的信息，并可以忽略。

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

为了防止在代理管理大量负载时发生 IO 相关问题，请验证 JVM 已分配有足够内存和堆空间。请参阅 ActiveMQSOURCE 文档的 Performance Tuning 一章中标题为 "Tuning the VM" 的部分。

ENTMQBR-648 - JMS Openwire 客户端无法通过定义的 purgeOnNoConsumer 或 queue 过滤器将消息发送到队列

如果队列没有消费者，使用 A-MQ 6 JMS 客户端将消息发送到带有 purgeOnNoConsumer 设置为 true 的队列的地址，会失败。在使用 A-MQ 6 JMS 客户端时，建议您不要设置 purgeOnNoConsumer 选项。

ENTMQBR-652 - 已知 amq-jon-plugin 错误列表

此版本的 amq-jon-plugin 已知的与 MBeans 用于代理和队列相关的问题。

代理 MBean 的问题：

队列 MBean 的问题：

ENTMQBR-655 - [AMQP] Unable to send message when populate-validated-user is enabled

对于使用 AMQP 协议生成的消息，配置选项 populate-validated-user 不被支持。

ENTMQBR-897 - 在目标名称中带有特殊字符的 Openwire 客户端/协议问题

目前，AMQ OpenWire JMS 客户端无法访问队列和地址，它们的名称中包含以下字符： comma comma(',')、hash('#')、大于('>')和空格。

ENTMQBR-944 - [A-MQ7, Hawtio, RBAC] 用户在 RBAC 拒绝操作时不会获得任何反馈

控制台可能会表示未授权用户尝试的操作在未成功时获得成功。

ENTMQBR-1875 - [AMQ 7, ha, replicated store] backup 代理看不到"live"或关机 - ActiveMQIllegalStateException errorType=ILLEGAL_STATE message=AMQ119026：备份服务器尚未与实时同步

在备份代理尝试与 master 代理同步时，删除 master 代理的分页磁盘会导致 master 失败。另外，备份代理无法变为 live，因为它继续尝试与 master 同步。

ENTMQBR-2068 - 在 HA 故障切换过程中收到一些消息但不提供。

目前，如果在 OpenWire 客户端发送信息时代理故障转移到它的从属服务器，则当故障转移丢失时向代理传输的消息。要临时解决这个问题，请确保代理会在确认信息前保留它们。

ENTMQBR-3331 - Stateful set controller 不能从 CreateContainerError 中恢复，阻止 Operator

如果 AMQ Broker Operator 从具有配置错误的自定义资源(CR)创建有状态集，则有状态集控制器无法在错误解决时回滚更新的有状态集。

例如，在主代理 CR 中 image 属性的值中拼写错误，会导致有状态集控制器创建的第一个 Pod 的状态保持 Pending。如果修复错误拼写并应用 CR 更改，AMQ Broker Operator 会更新有状态的集合。但是，Kubernetes 已知问题可防止有状态的集合控制器部署更新的有状态集。控制器会无限期地等待具有 Pending 状态变为 Ready 的 Pod，因此不会部署新的 Pod。

要临时解决这个问题，您必须删除状态为 Pending 的 Pod，以便有状态集控制器部署新 Pod。要检查哪些 Pod 是否有 Pending 状态，请使用以下命令： oc get pods --field-selector=status.phase=Pending。要删除 Pod，请使用 oc delete pod <pod name> 命令。

ENTMQBR-3846 - PlacementBinding 客户端在代理重启时不会重新连接

当您重启代理或者代理故障切换时，活跃代理不会恢复之前连接的 awx 客户端的连接。要临时解决这个问题，要重新连接 expertise 客户端，您需要在客户端上手动调用 subscribe（） 方法。

ENTMQBR-4023 - AMQ Broker Operator: Pod Status pod 名称不会反映实际情况

对于给定的 OpenShift 项目中的基于 Operator 的代理部署，如果使用 oc get pod 命令列出代理 Pod，则 Pod 的 ordinal 值从 0 开始，例如 amq-operator-test-broker-s-0。但是，如果您使用 oc describe 命令获取从 activemqartmises 自定义资源创建的代理 Pod 的状态（即 oc describe activemqartemises），则 Pod 或dinal 值在 1 中错误启动，例如 amq-operator-test-broker-s-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。如果其中有些名称很长，则默认路由名称可能会超过 OpenShift 强制执行的 63 个字符的限制。在本例中，在 OpenShift Container Platform Web 控制台中，Router 会显示 拒绝 的状态。

要临时解决这个问题，使用 OpenShift Container Platform Web 控制台手动编辑路由的名称。在控制台中，点 Route。在右上角的 Actions 下拉菜单中选择 Edit Route。在 YAML 编辑器中，找到 spec.host 属性并编辑值。

ENTMQBR-4140 - AMQ Broker Operator：如果 storage.size 不当指定，安装将变得不可用

如果您配置自定义资源(CR)实例的 storage.size 属性，以指定部署的持久性卷声明(PVC)大小，如果没有为持久性存储指定这个值，Operator 安装将无法使用。例如，假设您将 storage.size 的值设置为 1（即不指定单元）。在这种情况下，Operator 无法使用 CR 创建代理部署。另外，即使删除了 CR 并使用正确的 storage.size 部署新版本，Operator 仍然无法使用此 CR 创建部署。

要临时解决这个问题，首先停止 Operator。在 OpenShift Container Platform Web 控制台中点 Deployments。对于与 AMQ Broker Operator 对应的 Pod，点 More options 菜单（三个垂直点）。点 Edit Pod Count，将值设为 0。当 Operator Pod 停止后，创建带有正确指定 storage.size 的 CR 的新版本。然后，要重启 Operator，请再次点击 Edit Pod Count，并将值设为 1。

ENTMQBR-4141 - AMQ Broker Operator: Increasing Persistent Volume size 需要手动参与，即使恢复 Stateful 设置

如果您尝试增加部署用于持久性存储的代理所需的持久性卷声明(PVC)，则更改不会起作用，而无需进一步手动步骤。例如，假设您配置自定义资源(CR)实例的 storage.size 属性，以指定 PVC 的初始大小。如果您修改 CR 来指定 storage.size 的不同值，则现有代理将继续使用原始 PVC 大小。即使将部署缩减到零代理，然后再备份到原始数量，也是如此。但是，如果您扩展部署的大小来添加额外的代理，新代理会使用新的 PVC 大小。

要临时解决这个问题，并确保部署中的所有代理都使用相同的 PVC 大小，使用 OpenShift Container Platform Web 控制台扩展部署使用的 PVC 大小。在控制台中，点击 Storage → Persistent Volume Claims。点击您的部署。在右上角 Actions 下拉菜单中，选择 Expand PVC 并输入新值。