Spring AMQP 源码分析 05 - 异常处理

Posted 2020-09-28 首夜盲毒预言家

### 准备

## 目标

了解 Spring AMQP Message Listener 如何处理异常

## 前置知识

《Spring AMQP 源码分析 04 - MessageListener》

## 相关资源

Offical doc：<http://docs.spring.io/spring-amqp/docs/1.7.3.RELEASE/reference/html/_reference.html#exception-handling>

Sample code：<https://github.com/gordonklg/study>，rabbitmq module

源码版本：Spring AMQP 1.7.3.RELEASE

## 测试代码

gordon.study.rabbitmq.springamqp.AsyncConsumerWithErrorHandler.java

 

### 分析

## 消息消费异常处理流程

根据上一遍文章的分析，示例代码 AsyncConsumerWithErrorHandler 第26行开始消费消息，方法运行在 AsyncMessageProcessingConsumer 线程实例中，调用栈如下：

由 AbstractMessageListenerContainer 的 doInvokeListener 方法直接发起对 onMessage 方法的调用，代码如下：

对于 onMessage 消息处理过程中抛出的异常， wrapToListenerExecutionFailedExceptionIfNeeded 方法将所有非 ListenerExecutionFailedException 异常包装为 ListenerExecutionFailedException 异常（通过 instanceof 判断，因此 ListenerExecutionFailedException 子类不会被包装），并重新抛出。

 

调用栈一直退出，直到 SimpleMessageListenerContainer(AbstractMessageListenerContainer).executeListener(Channel, Message) line: 729   

 

handleListenerException 方法最终调用 invokeErrorHandler 方法，通过属性 ErrorHandler errorHandler 的 handleError 方法正式处理异常。

 

默认的 errorHandle 就是 ConditionalRejectingErrorHandler，其 handleError 逻辑很简单：如果抛出的异常，其原因链中不包含 AmqpRejectAndDontRequeueException，同时 ConditionalRejectingErrorHandler 内部属性 FatalExceptionStrategy exceptionStrategy 的 isFatal 方法返回 true（可以看成是无法恢复的严重异常），则将异常包装为 AmqpRejectAndDontRequeueException 重新抛出。

 

这是判断原因链中是否包含 AmqpRejectAndDontRequeueException 的代码：

 

 

默认情况下， exceptionStrategy 是 DefaultExceptionStrategy 的实例：

只有 ListenerExecutionFailedException 异常及其子类才可能是 fatal，但是对于本次调用栈，wrapToListenerExecutionFailedExceptionIfNeeded 方法保证了抛出的异常是 ListenerExecutionFailedException。

isCauseFatal 方法定义了一些严重异常，很显然，这些异常都是些无论重试多少次都会出错的异常，因此应该被包装为 AmqpRejectAndDontRequeueException  异常。

DefaultExceptionStrategy 预留了 isUserCauseFatal 方法给用户扩展。

 

异常继续往外抛，到 SimpleMessageListenerContainer.doReceiveAndExecute(BlockingQueueConsumer) line: 1260，会调用 BlockingQueueConsumer 的 rollbackOnExceptionIfNecessary 方法。该方法先判断是否要向 RabbitMQ 确认消息，如果需要确认（意味着要调用 channel 的 basicReject 方法），再根据异常的原因链中是否存在 AmqpRejectAndDontRequeueException 异常决定如何设置  basicReject 方法的 requeue 参数。

 

## 示例代码分析

从流程分析中可知，onMessage 方法如果抛出异常，一般情况下会导致消息被 reject，同时重新入队。这个默认设置比较安全。

 

如果我们不想要消息重新入队呢？最简单的方法就是抛出 AmqpRejectAndDontRequeueException，就像示例代码中被注释掉的第33行代码那样。但是这导致业务消费逻辑与框架实现绑定过深，因此，我们采用重载 DefaultExceptionStrategy 的 isUserCauseFatal 方法来决定不同的业务异常要不要让 reject 的消息重新入队，正如示例代码第42行所示。当异常类型是 UserDefineException 时，消息被 reject 同时不会重入队列。