ActiveMQ Artemis如何查看调度消息并取消延迟立即重投递

为什么browse()无法查看调度等待状态的消息 #

这是ActiveMQ Artemis的原生存储设计决定的：

• 等待调度投递的消息不会存放在队列的常规可投递消息段，而是单独存放在专属的调度消息存储区，只有到了预设的投递时间点，broker才会把消息从调度区移动到常规待投递队列，供消费者拉取、或者被browse()方法枚举到。
• browse()方法的设计目标就是仅查询当前已经就绪、可被立即消费的消息，不会主动扫描调度存储区，因此看不到等待中的调度消息是正常行为，并非消息丢失。常规的队列深度统计默认也不会计入调度区的消息，很多用户误判消息丢失都是因为这个设计。
• listScheduledMessages()是专门面向调度存储区的查询接口，只有调用这类专属接口才能拿到调度中的消息数据。较新版本的Artemis管理控制台，在队列详情页已经提供了独立的「Scheduled Messages」标签页，切换后就能直接看到所有等待调度的消息，不需要手动执行方法调用。

跳过调度等待立即触发消息重投递的方法 #

不需要等待预设的延迟周期，可以直接通过管理接口操作触发立即重投：

• 单条消息操作：先调用listScheduledMessages()获取目标消息的messageID，之后直接调用队列的retryScheduledMessage(messageID)方法，传入对应消息ID，broker会立刻把该消息从调度存储区移动到常规待投递队列，触发重投递。整个过程会保留消息原有的重试计数、自定义属性、投递头信息，不会破坏原有阶梯重投规则的计数逻辑。不管是通过Web控制台的方法执行面板，还是JMX、HTTP Jolokia管理接口调用该方法，效果完全一致。
• 批量操作：如果需要把某队列所有调度中的消息都立即重投，可以先通过listScheduledMessages()拿到所有调度消息的ID集合，循环调用retryScheduledMessage()方法即可。

注意：不要使用删除调度消息后重新发送、移动消息到其他队列再移回的方式操作，这类操作会重置消息的重试计数，甚至丢失部分消息头属性，导致阶梯重投规则失效。

内容的提问来源于stack exchange，提问作者treo