ActiveMQ Artemis Last Value Queue定时消息更新支持验证及解决方案咨询

没错，Artemis的LVQ机制确实是等消息到达可投递状态时才会触发last-value-key的评估和替换逻辑。对于带延迟投递的消息，它们会先被存放在Artemis的内部调度队列（$sys.sched.<你的队列名>）里，直到延迟时间到期才会被移到目标LVQ——这时候才会检查是否有同key的消息需要替换。这就导致你现在遇到的问题：新发送的同key延迟消息没法直接替换还在调度队列里等待的旧消息。

接下来针对你的需求（用新版本消息替换队列中已有的定时消息，同时更新投递时间），给你几个可行的方案：

方案1：直接操作Artemis核心API（推荐，最精准） #

Spring JMS是JMS规范的封装，没法直接访问Artemis的底层调度队列，所以咱们可以获取Artemis的ClientSession来手动清理旧的延迟消息。步骤很清晰：

1. 从你的ConnectionFactory获取Artemis原生的ActiveMQConnection，进而创建ClientSession
2. 定位到目标队列对应的内部调度队列（命名规则是$sys.sched.<目标队列名>）
3. 遍历调度队列，筛选出带有目标uniqueJobId的旧延迟消息并删除
4. 再发送新的延迟消息

调整你的QueueMessageService代码如下：

public class QueueMessageService {
    @Resource
    private JmsTemplate jmsTemplate;
    @Resource
    private ConnectionFactory connectionFactory;

    public void queueJobRequest(
            final String queue,
            final int priority,
            final long deliveryDelayInSeconds,
            final MyMessage jobRequest) {
        // 先清理调度队列里的旧消息
        removeOldScheduledMessage(queue, jobRequest.getUniqueJobId().toString());
        
        // 发送新的延迟消息
        jmsTemplate.convertAndSend(queue, jobRequest, message -> {
            message.setJMSPriority(priority);
            if (deliveryDelayInSeconds > 0 && deliveryDelayInSeconds <= 86400) {
                message.setLongProperty(
                        Message.HDR_SCHEDULED_DELIVERY_TIME.toString(),
                        Instant.now().plus(deliveryDelayInSeconds, ChronoUnit.SECONDS).toEpochMilli()
                );
            }
            message.setStringProperty(Message.HDR_LAST_VALUE_NAME.toString(), "uniqueJobId");
            message.setStringProperty("uniqueJobId", jobRequest.getUniqueJobId().toString());
            return message;
        });
    }

    private void removeOldScheduledMessage(String targetQueue, String uniqueJobId) {
        // Artemis内部调度队列的固定命名格式
        String scheduledQueueName = "$sys.sched." + targetQueue;
        
        try (ActiveMQConnection connection = (ActiveMQConnection) connectionFactory.createConnection();
             ClientSession session = connection.createSession()) {
            connection.start();
            ClientQueue scheduledQueue = session.createQueue(scheduledQueueName);
            
            // 遍历调度队列找目标消息
            try (ClientQueueBrowser browser = session.createBrowser(scheduledQueue)) {
                ClientMessage message;
                while ((message = browser.getNextMessage()) != null) {
                    String msgJobId = message.getStringProperty("uniqueJobId");
                    if (uniqueJobId.equals(msgJobId)) {
                        session.deleteMessage(message.getMessageID());
                        break; // LVQ只保留一条同key消息，找到就停止遍历
                    }
                }
            }
        } catch (Exception e) {
            throw new RuntimeException("Failed to clean up old scheduled message", e);
        }
    }
}

这个方案能精准控制旧消息的删除，完全匹配你的需求，而且因为用了try-with-resources，会话和连接会自动关闭，不用担心资源泄漏。

方案2：利用Artemis的消息ID追踪（备选） #

如果不想遍历调度队列，你可以在发送旧消息时记录它的messageID，当需要发送新版本时，直接用ClientSession.deleteMessage()删除旧消息。但这个方案需要额外存储messageID和uniqueJobId的映射关系（比如用Redis或者本地缓存），复杂度会高一些，适合消息量特别大的场景。

方案3：避免使用延迟投递，改用定时任务触发（不推荐） #

如果上面的方案都不太适合，你可以考虑把消息先存在数据库里，用定时任务（比如Quartz）在指定时间把消息发送到LVQ。这样新消息直接覆盖数据库里的旧记录，定时任务只发送最新的那条。但这个方案相当于自己实现了调度逻辑，会增加系统复杂度，除非你已经有成熟的定时任务体系。

额外提醒 #

• 因为你用的是嵌入式Artemis，确保ClientSession的操作是线程安全的——示例里每次调用都创建新会话，是线程安全的。
• 内部调度队列是Artemis的系统队列，不要修改它的配置，只做查询和删除操作即可。
• 你的队列用的是ANYCAST，调度队列的命名规则是固定的；如果是MULTICAST队列，调度队列名会带路由组后缀，但你的场景里用不上。

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