anchor.diff:  However, when all fails, the exceptions thrown by the message handlers are propagated back to the binder. At that point, binder invokes custom error handler or communicates
   the error back to the messaging system (re-queue, DLQ, and others).
   
  -===== Application Error Handling
  +==== Application Error Handling
   
   There are two types of application-level error handling. Errors can be handled at each binding subscription or a global handler can handle all the binding subscription errors. Let's review the details.
   
  
positive.code: Once set, the failed message is resubmitted to the same handler and loops continuously or until the handler throws `AmqpRejectAndDontRequeueException`
  essentially allowing you to build your own re-try logic within the handler itself.
  
  ===== Retry Template
  
  The `RetryTemplate` is part of the https://github.com/spring-projects/spring-retry[Spring Retry] library.
  While it is out of scope of this document to cover all of the capabilities of the `RetryTemplate`, we will mention the following consumer properties that are specifically related to
  
negative.code: Both Rabbit and Kafka support these concepts. However, other binders may not, so refer to your individual binder’s documentation for details on supported system-level
  error-handling options.
  
  ===== Drop Failed Messages
  
  By default, if no additional system-level configuration is provided, the messaging system drops the failed message.
  While acceptable in some cases, for most cases, it is not, and we need some recovery mechanism to avoid message loss.
  
  ===== DLQ - Dead Letter Queue
  
  DLQ allows failed messages to be sent to a special destination: - _Dead Letter Queue_.
  
  