@JmsListener抛出MessageConversionException，如何非阻塞接收IBM MQ消息

错误根因 #

Spring 原生的@JmsListener是基于阻塞Servlet栈设计的，本身没有对Reactor响应式类型（Mono/Flux）的返回值做适配。当你返回Mono<Void>时，Spring JMS会把Mono对象本身当做普通JMS消息的Payload尝试序列化，而Mono没有实现Serializable接口，自然就触发了MessageConversionException；改为void后不会触发返回值的消息转换逻辑，所以运行正常。

解决方案 #

方案1：void方法内主动订阅响应式逻辑（改造成本最低） #

保持方法返回值为void，在方法内部对响应式逻辑手动配置线程调度后订阅，避免阻塞JMS监听线程：

@JmsListener(destination = "queue", containerFactory = "Factory", id = "start")
public void requestProcess(Message message, Session session) {
    // 业务响应式逻辑
    Mono.defer(() -> {
        // 此处编写实际业务处理逻辑，比如解析message、调用响应式DAO/接口等
        return Mono.just("业务处理完成");
    })
    // 调度到响应式线程池执行，不占用JMS监听线程
    .subscribeOn(Schedulers.boundedElastic())
    // 处理正常逻辑，手动ack消息（仅CLIENT_ACKNOWLEDGE模式需要）
    .doOnSuccess(res -> {
        try {
            message.acknowledge();
        } catch (JMSException e) {
            throw new RuntimeException("消息确认失败", e);
        }
    })
    // 处理异常逻辑，触发消息重试/入死信队列
    .doOnError(e -> {
        try {
            session.recover();
        } catch (JMSException ex) {
            throw new RuntimeException("消息恢复失败", ex);
        }
        // 自行打印异常日志
        log.error("消息处理失败", e);
    })
    // 触发订阅执行逻辑
    .subscribe();
}

如果使用自动ack模式，不需要手动调用ack方法，只要保证异常捕获逻辑完整即可。

方案2：使用响应式JMS组件（全响应式栈） #

如果需要全链路响应式，直接弃用Spring原生@JmsListener，改用支持响应式的JMS集成方案：

• 引入IBM MQ官方响应式客户端，配合SmallRye Reactive Messaging或者Spring Integration的响应式JMS端点
• 配置响应式消息监听容器，直接对接Reactor流，完全脱离阻塞JMS线程模型

注意事项 #

• 不要在JMS监听线程中执行任何阻塞操作，所有IO逻辑必须放到响应式线程池调度
• 订阅响应式逻辑时必须显式处理异常，避免异常静默丢失导致业务故障
• 手动ack场景下，必须等业务逻辑执行完成后再确认消息，避免业务未执行完消息提前被确认导致数据丢失

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