# # Ready# # Goal Understanding Spring AMQP Message Listener How to handle exceptions # # PRE-Knowledge "spring AMQP source Analysis 04-messagelistener"# # Related Resources Offical doc:
gordon.study.rabbitmq.springamqp.AsyncConsumerWithErrorHandler. Java # # # Analysis # # Message consumption exception processing flow based on the analysis of the previous article, sample code Asyncconsumerwitherrorhandler line 26th begins consuming messages, and the method runs onAsyncmessageprocessingconsumerIn the thread instance, the call stack is as follows:
ByAbstractmessagelistenercontainerOfDoinvokelistenerThe OnMessage method directly initiates a call to the method, and the code is as follows: For exceptions thrown during onMessage message processing,wraptolistenerexecutionfailedexceptionifneededmethod will all non-listenerexecutionfailedexceptionthe exception wrapper islistenerexecutionfailedexceptionexceptions (judged by instanceof, so listenerexecutionfailedexception subclasses are not wrapped) and re-thrown. the call stack exits until Simplemessagelistenercontainer (Abstractmessagelistenercontainer). Executelistener (Channel, Message ) line:729 handlelistenerexceptionMethod is eventually calledInvokeerrorhandlerMethod, by propertyErrorHandler ErrorHandlerOfHandleErrorMethod formally handles exceptions. The defaultErrorhandleIt isConditionalrejectingerrorhandler, its handleError logic is simple: If the exception is thrown, its cause chain does not containamqprejectanddontrequeueexception, whileConditionalrejectingerrorhandlerInternal propertiesfatalexceptionstrategy exceptionstrategyThe Isfatal method returns True (can be seen as a fatal exception that cannot be recovered), the exception is wrapped asamqprejectanddontrequeueexceptionRe-throw. It's a judgment.Whether the reason chain containsamqprejectanddontrequeueexceptionThe code:By default,ExceptionstrategyIs DefaultexceptionstrategyInstances of:OnlylistenerexecutionfailedexceptionThe exception and its subclasses may be fatal, but for this call stack,wraptolistenerexecutionfailedexceptionifneededMethod ensures that the thrown exception is listenerexecutionfailedexception. The iscausefatal method defines some serious exceptions, and it is clear that these exceptions are
exceptions that can be faulted regardless of how many times they are retried, and therefore should be packaged asamqprejectanddontrequeueexception exception. DefaultexceptionstrategyReserved aIsusercausefatalMethod is extended to the user.
The exception continues to be thrown out to Simplemessagelistenercontainer.doreceiveandexecute (Blockingqueueconsumer) line:1260, which invokes theBlockingqueueconsumerOfrollbackonexceptionifnecessaryMethod. This method first determines whether to confirm the message to the RabbitMQ, if it needs to be confirmed (meaning that the channel'sBasicrejectmethod), and then, depending on the cause of the exception in the chainamqprejectanddontrequeueexceptionExceptions determine how to set Basicrejectmethod ofThe requeue parameter. # # # # # # # # # # # # # # # example code analysis from the process analysis, the OnMessage method throws an exception, normally causes the message to be reject and re-queued. This default setting is more secure. What if we don't want the news to be re-queued? The simplest way is to throwamqprejectanddontrequeueexception, just like the 33rd line of code that is commented out in the sample code. But this leads to a binding of the business consumption logic to the framework implementation, so we take the overloadedDefaultexceptionstrategy Isusercausefatal method to determine the different business exceptions to let the reject message be re-queued, as shown in line 42nd of the sample code. When the exception type is userdefineexception, the message is reject and does not re-enter the queue.
Spring AMQP Source Analysis 05-Exception handling
