如何在Azure Service Bus中通过JMS为死信队列消息设置DeadLetterReason

问题根源 #

你当前通过直接设置JmsMessage的DeadLetterReason和DeadLetterErrorDescription属性，再手动触发ack的方式，无法让Azure Service Bus JMS客户端将这些属性同步到死信队列的消息中。这是因为Azure的JMS客户端在处理REJECT类型的ack时，不会读取你设置的这些属性，而是需要通过其原生API传递死信原因参数。

解决方案 #

放弃反射操作内部Session的方式，直接使用Azure Service Bus JMS客户端提供的deadLetter方法来完成死信操作，该方法会自动将原因和描述属性添加到死信消息中。

修改后的ServiceBusHelper代码 #

import com.azure.spring.messaging.servicebus.core.ServiceBusJmsMessage;

// ... 其他依赖注入和日志声明

public void moveToDeadLetterQueue(JmsMessage message, Exception reason) throws JMSException {
    if (!(message instanceof ServiceBusJmsMessage serviceBusMessage)) {
        throw new IllegalArgumentException("仅支持Azure Service Bus的JMS消息类型");
    }

    String deadLetterReason = reason.getClass().getSimpleName();
    String errorDescription = reason.getMessage();
    
    // 使用原生API死信消息并传递原因
    serviceBusMessage.deadLetter(deadLetterReason, errorDescription);
    
    log.info("Moved message: {}, to dead letter queue due to: {}", message.getJMSCorrelationID(), deadLetterReason);
}

简化后的JmsListener方法 #

现在不需要再传入Session参数，也不需要处理反射相关的异常：

@JmsListener(
        destination = "topic-name",
        containerFactory = "topicJmsListenerContainerFactory",
        subscription = "subscription-name"
)
public void receive(JmsMessage message) throws JMSException, JsonProcessingException {
    log.info("Message received from {} : {}", subscriptionName, message.getJMSMessageID());
    try {
        StatusDto status = service.process(parseMessageToDto(message), message.getJMSCorrelationID());
        log.info("Message: {} sent with success. Status: {}", message.getJMSCorrelationID(), mapper.writeValueAsString(status));
        // 正常处理完成后手动确认消息
        message.acknowledge();
    } catch (FatalException | JsonProcessingException | ConstraintViolationException exception) {
        serviceBusHelper.moveToDeadLetterQueue(message, exception);
    }
}

关键说明 #

• 原生API的优势：ServiceBusJmsMessage.deadLetter()是Azure官方提供的死信操作方式，会自动处理死信消息的属性设置、路由等逻辑，彻底避免反射带来的版本兼容性问题。
• 配置无需改动：你当前的client确认模式配置完全适配该方案，不需要修改application.properties中的JMS配置。
• 异常边界：确保只在明确的致命错误场景下调用死信方法，避免正常业务异常被误丢到DLQ。

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