搜索

第 7 章 已知问题

download PDF

本节论述了 AMQ Broker 7.8 中的已知问题。

  • ENTMQBR-17 - AMQ222117:无法启动集群连接

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

  • ENTMQBR-463 - 集群设置中的属性具有顺序限制。最好有一条更好的错误消息,或者只是忽略顺序

    目前,集群连接配置中的元素序列需要按特定顺序排列。解决办法是遵循配置方案中的顺序。

  • ENTMQBR-520 - 不允许从名称与另一个地址绑定的地址接收。

    名称与地址相同的队列只能分配给地址。创建与现有地址相同的队列,但绑定到具有不同名称的地址是无效的配置。这样做可能会导致将不正确的消息路由到队列中。

  • ENTMQBR-522 - 在窗口上运行的代理编写问题,并在关闭时删除临时文件

    在 Windows 上,代理不会在关闭时成功清理临时文件。此问题会导致关闭过程很慢。另外,代理会不断积累了不被代理删除的临时文件。

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

    当从 A-MQ 6 OpenWire 客户端与 AMQP 客户端通信跨协议时,将在应用程序消息属性中编码其他信息。这是代理内部使用的 benign 信息,可以忽略。

  • ENTMQBR-599 - 由 Artemis cli 定义信任存储和密钥存储

    使用 --ssl-key、--ssl-key-password、-- ssl-trust 和 --ssl-trust -password 参数创建代理实例将无法正常工作。要临时解决这个问题,在创建代理后手动设置 bootstrap.xml 中的对应属性。

  • ENTMQBR-636 - Journal break,导致 perf 负载下 JavaNullPointerException

    为防止代理管理重重负载时发生 IO 相关问题,请验证 JVM 是否已分配足够内存和堆空间。请参阅 ActiveMQ Artemis 文档中的 性能调优 章节中标题为"虚拟机"的部分。

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

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

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

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

    broker MBean 的问题:

    • 关闭连接会引发 java.net.SocketTimeoutException 异常
    • listSessions() throws java.lang.ClassCastException
    • 添加地址设置会引发 java.lang.IllegalArgumentException
    • getConnectorServices() 操作无法找到
    • 无法找到 listConsumersAsJSON() 操作
    • 无法找到 getDivertNames() 操作
    • 列出网络拓扑会抛出 IllegalArgumentException
    • 删除地址设置有错误的参数名称

    队列 MBean 的问题:

    • expireMessage() 丢弃参数类型不匹配异常
    • listDeliveringMessages() throws IllegalArgumentException
    • listMessages() throws java.lang.Exception
    • moveMessages() throws IllegalArgumentException 带有错误消息参数类型不匹配
    • removeMessage() throws IllegalArgumentException 带有错误消息参数类型不匹配
    • removeMessages() 抛出异常,错误 Can't find removeMessage with 2 参数
    • retryMessage() throws 参数类型不匹配 IllegalArgumentException
  • ENTMQBR-655 - [AMQP] 在启用 fill -validated-user 时无法发送消息

    对于使用 AMQP 协议生成的消息,配置选项不支持 填充-validated-user

  • ENTMQBR-738 - 通过提供离线存储库离线构建 AMQ 7 示例

    您不能在离线环境中构建 AMQ Broker 中包含的示例。造成这个问题的原因是,提供的离线 Maven 存储库中缺少依赖项。

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

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

  • ENTMQBR-944 - [A-MQ7、Hwtio、RBAC] 用户在 RBAC 拒绝操作访问时不会获得反馈

    控制台可以指示未授权用户当没有成功时尝试的操作被成功。

  • ENTMQBR-1498 - HA(复制、共享存储)的管理控制台图不反映真正的拓扑

    如果您使用一些额外的被动从设备配置代理集群,Web 控制台中的集群图不会显示这些被动的从设备。

  • ENTMQBR-1848 - "javax.jms.JMSException:队列的路由类型不正确,预期为:当 qpid-jms 客户端使用来自多播队列的消息为 javax.jms.Queue 对象时,会发生 ANYCAST"。

    目前,通过将 Qpid JMS 客户端使用 FQQN(完全限定队列名称)发送到配置了多个队列的地址,这会在客户端上生成错误消息,并且该消息无法发送。要临时解决这个问题,修改代理配置以解决错误并取消阻塞客户端。

  • ENTMQBR-1875 - [AMQ 7、ha、Replica store] 备份代理似乎在 - ActiveMQIllegalStateException 错误Type=ILLEGAL_STATE message=AMQ119026 后出现。备份服务器尚未与 live 同步

    当备份代理试图与 master 代理同步时,删除 master 代理的分页磁盘会导致 master 代理失败。另外,备份代理将无法变为现实,因为它继续尝试与 master 同步。

  • 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 consumer,但消费者在消耗消息前关闭,代理会错误地递增待处理消息的重新发送计数。如果出现此行为的数量超过 max-delivery-attempts 配置参数的值,代理会将消息发送到死信队列(DLQ),或者根据您的配置丢弃消息。这个问题不会影响其他协议,如核心协议。

  • ENTMQBR-2593 - 代理不会在跨协议消耗中设置消息 ID 标头

    只有在被另一 Qpid JMS 客户端生成消息时,Qpid JMS 客户端才会成功检索消息 ID。如果消息由核心 JMS 或 OpenWire 客户端生成,则 Qpid JMS 客户端无法读取消息 ID。

  • ENTMQBR-2678 - 在隔离的 master 处于活动状态后,它无法连接到集群

    在三个或更多使用复制高可用性(HA)策略的实时备份组中,实时代理会在复制连接失败时关闭。但是,当恢复复制连接时,原始 live 代理被重启时,代理有时无法重新加入代理集群。要启用原始实时代理重新加入集群,首先停止新的实时(原始备份)代理,重启原始实时代理,然后重启原始备份代理。

  • ENTMQBR-2928 - Broker Operator 无法从 CR 更改中恢复,从而导致错误的状态

    如果在应用自定义资源(CR)更新时,如果 AMQ Broker Operator 遇到错误,Operator 不会恢复。特别是,Operator 会停止响应,以便进一步更新 CR。

    例如,如果主代理 CR 中的 image 属性的值出现错误拼写,则代理 Pod 将无法部署,且相关的错误消息为 ImagePullBackOff。如果修复拼写错误并应用 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)如果单个剩余代理 Pod 的日志条目为"未知主机异常",将部署扩展为零代理 Pod,然后返回到一个代理 Pod。

    4)当您验证单个剩余代理 Pod 没有记录基于异常的日志条目时,请将您的部署扩展至其原始大小。

  • ENTMQBR-3131 - 当 Master 为 Killed 时,Topology Fails 无法正确更新备份代理

    当一个集群中有超过四个 live-backup 对的 live 代理失败时,实时代理(包括新选择的实时代理)会正确报告更新的拓扑。但是,剩余的备份代理可能会以以下方法显示错误拓扑:

    • 如果备份代理故障转移了失败的 live 代理,则剩余的备份代理会在拓扑中显示这个备份代理两次。
    • 如果备份代理还没有失败,则剩余的备份代理仍然会在拓扑中显示失败的实时代理。

    要临时解决这个问题,请确保 cluster-connection > static-connectors 配置每个备份代理的第一个 connector-ref 元素指定了预期的 live 代理。

  • ENTMQBR-3604 - 为 LDAP 登录模块使用关闭启用池(Hang)

    如果您为 LDAP 供应商启用连接池(即,在 login.config 配置文件的 LDAPLoginModule 部分中将 connectionPool 设置为 true ),这将导致到 LDAP 供应商的连接保持开放,即使您停止代理客户端也是如此。因此,如果您尝试以正常方式关闭代理,代理不会关闭。反之,您需要使用一个 Linux 命令(如 SIGKILL )终止代理进程。即使您在 JVM 参数中指定池超时(例如,-Dcom.sun.jndi.ldap.connect.pool.timeout=30000),并且当尝试关闭代理时没有活跃的客户端。

    要临时解决这个问题,请在 login.config 配置文件的 LDAPLoginModule 部分中为 connectionTimeout 属性设置一个值。当为连接池请求连接池时,connectionTimeout 属性指定当最大池大小已达到并且池中所有连接都处于连接的最长时间。如需更多信息,请参阅配置 AMQ Broker 中的 使用 LDAP 进行身份验证

  • ENTMQBR-3724 - OperatorHub 显示在 AMQ Broker Operator 的变体

    如果使用 OperatorHub 在 OpenShift Container Platform 4.5 或更早版本部署 AMQ Broker Operator,则 OperatorHub 会显示一个与主机平台相关的 Operator 变体。这样便可选择不正确的 Operator 变体。特别是,无论您的主机平台是什么,Operator 会显示 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 状态 pod 名称没有反映现实

    对于给定 OpenShift 项目中的基于 Operator 的代理部署,如果您使用 oc get pod 命令列出代理 Pod,则 Pod 的 ordinal 值从 0 开始,如 amq-operator-test-broker-s-0。但是,如果您使用 oc describe 命令获取从 activemqartmises 自定义资源(即 oc describe activemqartemises)创建的代理 Pod 的状态,则 Pod 或dinal 值从 1 不正确启动,例如 amq-operator-test-broker-ss-1。无法解决这个问题。

  • ENTMQBR-4127 - AMQ Broker Operator:Operator 生成的路由名称可能太长于 OpenShift

    对于基于 Operator 的部署中的每个代理 Pod,Operator 创建用于访问 AMQ Broker 管理控制台的路由的默认名称包括自定义资源(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 的名称。在控制台中,点 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:增加持久性卷大小需要即使在重新创建 Stateful 设置后手动参与

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

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.