4.19.2. 环队列故障排除

本节介绍环队列的行为与其配置不同的情况。

in-delivery 消息和回滚

当消息正在传送到消费者时，消息处于"中间"状态，其中消息在技术上不再在队列中，但也尚未确认。消息一直处于传送中状态，直到被消费者确认。处于传送中状态的消息不能从环队列中删除。

因为代理无法删除传送中的消息，所以客户端可以发送比环大小配置更多的消息。例如，考虑这种情况：

制作者向配置了 ring-size="3" 的环队列发送三条消息。
所有消息都会立即分配给消费者。
此时，Message Count= 3 和 delivery Count= 3。
制作者向队列发送另一条消息。该消息随后被分配给消费者。
现在，MessageCount = 4 和 deliveryCount = 4。消息数 4 大于配置的环大小 3。但是，代理会坚持允许这种情况，因为它无法从队列中删除传输中消息。
现在，假设消费者未拒绝任何消息即可关闭。
在这种情况下，四个未确认的消息将被取消到代理，并按使用它们的相反顺序添加到队列头。此操作在其配置的环大小上放置队列。由于环队列将队列末尾的消息优先于头条消息，因此队列会丢弃制作者发送的第一条消息，因为这是最近一次添加回队列头的消息。事务或核心会话回滚的方式相同。

如果您直接使用核心客户端，或者使用 AMQ 核心协议 JMS 客户端，您可以通过减少 consumerWindowSize 参数的值来最小化传输中的消息数量（默认为 1024 * 1024 字节）。

计划的消息

将计划的消息发送到队列时，该消息不会像普通消息一样立即添加到队列的尾部。相反，代理将计划的消息保存在中间缓冲区中，并根据消息的详细信息将消息调度到队列的头部。但是，调度的消息仍会反映在队列的消息计数中。与传送中消息一样，这种行为可使它似乎代理没有强制实施环队列大小。例如，考虑这种情况：

在 12:00 时，制作者将消息 A 发送到配置了 ring-size="3" 的环队列。该消息计划为 12:05。
此时，Message Count= 1 和 schedule Count= 1。
在 12:01 时，制作者将消息 B 发送到同一环队列。
现在，MessageCount= 2 和 scheduledCount= 1。
在 12:02 时，制作者将消息 C 发送到同一环队列。
现在，MessageCount= 3 和 scheduledCount= 1。
在 12:03 时，制作者将消息 D 发送到同一环队列。
现在，MessageCount= 4 和 scheduledCount= 1。
队列的消息数现在为 4，一个大于配置的环大小 3。但是，调度的消息尚不在队列中（即，它位于代理中并调度到队列中）。在预定的交付时间为 12:05 时，代理会将消息放在队列的头部。但是，由于环队列已达到其配置大小，计划的消息 A 将立即被删除。

页面信息

与传输中调度的消息和消息类似，分页消息不计入代理强制执行的环队列大小，因为消息实际上是在地址级别上分页的，而不是队列级别。分页消息在队列上不是在技术上进行的，尽管它反映在队列的 messageCount 值中。

建议您不要将分页用于具有环队列的地址。相反，请确保整个地址可适合内存。或者，将 address-full-policy 参数配置为 DROP、BLOCK 或 FAIL 的值。

其它资源