Back pressure / requeuing limit

[shark300]

Hey Guys,
We are using RabbitMQ as a middleware between our microservices (10+) which are written in Java using Spring Boot/Spring Integration/Spring AMQP.
We have implemented parking-lot-style retry mechanism yet, but we have an issue: we would like to reduce the cost of logging (we are using DataDog) without losing traceability of incoming messages. One of our microservices calls a very unstable external service, and it fails sometimes. In this case, a lot of messages are logged in same style:

@RabbitListener(
      id = "formReceiver",
      queues = INCOMING_QUEUE_SPEL,
      errorHandler = "formRabbitErrorHandler")
public void receive(Message original, @Valid Form form) {
   logger.info("Received message: {}", original); 
   try {
      somethingService.process(form);
    } catch (RetrySendMailException ex) {
      throw new ImmediateRequeueAmqpException(ex);
    } catch (Exception ex) {
      throw new AmqpRejectAndDontRequeueException(ex);
    }
}

public class FormRabbitErrorHandler implements RabbitListenerErrorHandler {

  private final Logger logger;

  @Autowired
  public FormRabbitErrorHandler(Logger logger) {
    this.logger = logger;
  }

  @Override
  public Object handleError(
      Message amqpMessage,
      org.springframework.messaging.Message<?> message,
      ListenerExecutionFailedException exception) {
    logger.warn("Execution of Rabbit message listener failed.", exception);
    throw exception;
  }
}

If an error is occurred, message will be requeued, and it's fine. But a lot of messages will be logged which increases the cost of operation.
As I see, we have some options:

• implements a custom retry as we are have with delayed messages
• implement a retry for external system
• exponential backoff
• limit message broking of RabbitMQ (back pressure?)

So to recap, are there any way to reduce/limit the throughput on RabbitMQ side?
Thanks.

[lukebakken]

So to recap, are there any way to reduce/limit the throughput on RabbitMQ side?

There is not.

[shark300]

Thanks @lukebakken