Spring Boot整合QPID JMS消费Azure服务总线队列报错后后续消息直接进DLQ问题

最高概率的根因是消费线程被JavaMail的网络IO长期阻塞占满：
线上SMTP故障时，默认配置的JavaMail没有设置网络超时阈值，会无限等待网络响应，导致@JmsListener对应的消费线程全部卡在邮件发送逻辑上，没有可用线程处理后续新消息。这些未被消费的消息超过Azure Service Bus的消费超时阈值后，就会被服务端直接判定为消费失败，送入DLQ。
你本地无法复现是因为测试时是直接抛出异常，线程会快速释放，不会出现长期阻塞占满线程池的场景。
其他可能的次要原因如下：

• QPID JMS客户端的预取（prefetch）配置过高，大量消息被提前拉取到客户端缓存，等待消费超时后直接进入DLQ
• 你填写的SessionsAcknownlegdeMode存在拼写错误，正确拼写为SessionsAcknowledgeMode，错误配置会导致CLIENT_ACKNOWLEDGE模式不生效，影响消息重试、确认的逻辑

1. 优先排查线程栈
   线上出现问题时立即导出线程栈，确认所有@JmsListener对应的消费线程是否都卡在JavaMail的网络IO操作上，验证根因。
2. 补全JavaMail超时配置
   给JavaMail添加强制超时配置，避免网络故障时线程无限阻塞，单位为毫秒，可根据业务需求调整：

spring.mail.properties.mail.smtp.connectiontimeout=5000
spring.mail.properties.mail.smtp.timeout=5000
spring.mail.properties.mail.smtp.writetimeout=5000

3. 调整QPID预取配置
   降低QPID JMS客户端的预取数量，避免大量消息提前拉取到本地后无法及时消费导致超时，可配置为jms.prefetchPolicy.all=1或者更小的数值匹配你的消费速度。
4. 修正JMS配置拼写错误
   将错误的SessionsAcknownlegdeMode改为正确的SessionsAcknowledgeMode，保证CLIENT_ACKNOWLEDGE模式生效，消息重试、DLQ流转逻辑符合预期。
5. 优化消费链路避免阻塞
   将邮件发送这类易阻塞的IO操作从消费主线程中剥离，提交到独立的异步线程池执行，消费主线程仅做消息接收、参数校验、异步任务提交的逻辑，快速完成消息确认，避免阻塞主消费流程。如果邮件发送失败，单独记录日志或做异步重试，不要影响主消息消费。
6. 可选：调大消费并发数
   可以适当调大@JmsListener注解的concurrency参数，例如@JmsListener(destination = "xxx", concurrency = "3-10")，预留足够的消费线程应对偶发的阻塞场景。

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