When rabbitMQ is down in spring boot, startup time increases due to connection retries

Question

I have a spring boot micro service application and I am using spring-cloud-stream-binder-rabbit All my rabbiqMq configurations are working fine but if rabbitMq goes down, consumers keeps attempting to fetch the connection indefinitely increasing the service startup time. When rabbitMq is up, it takes <30s, when rabbitMQis down, it takes around 270 seconds Is there a way to stop looking for connections after certain times?

This also causes my application to go down affecting all the APIs that are not related to rabbitMQ. I tried looking for properties I could add in application.properties to overcome this but couldn't find one.

@EnableBinding({HelperMQChannel.class})
public class MyTestServerApplication{

    public static void main(String[] args) {
        SpringApplication.run(MyTestServerApplication.class, args);
    }
}

public interface HelperMQChannel {

    @Input("testConsumerChannel")
    SubscribableChannel testConsumerChannel();

    @Output("testConsumerErrorPublishChannel")
    MessageChannel testConsumerErrorPublishChannel();
}

@Component
public class TestConsumerListener {

    @StreamListener("testConsumerChannel")
    public void processMessage(@NonNull RandomDto randomDto,
                               @Header(name = QueueConstants.X_DEATH, required = false) Map<String, Object> retryCount) {
          // my business logic

    }
}

Also tried creating a bean for RabbitTemplate as mentioned in https://stackoverflow.com/a/42399165/3883540 but still no luck as I dont even see the log message in my logs

    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        RabbitTemplate template = new RabbitTemplate(connectionFactory);

        RetryTemplate retryTemplate = new RetryTemplate();
        /*FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy();
        retryTemplate.setBackOffPolicy(fixedBackOffPolicy);

        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();
        retryPolicy.setMaxAttempts(2);
        retryTemplate.setRetryPolicy(retryPolicy);
        */
        template.setRetryTemplate(retryTemplate);


        RecoveryCallback<?> callback = (RecoveryCallback<Object>) retryContext -> {
            log.error("Nothing to do");
            return null;
        };

        template.setRecoveryCallback(callback);
        return template;
    }

This is what I see in logs

2022-11-15 17:06:01 [test-exchange.test-consumer-channel-2] WARN  o.s.a.r.l.SimpleMessageListenerContainer.logConsumerException - Consumer raised exception, processing can restart if the connection factory supports it. Exception summary: org.springframework.amqp.AmqpConnectException: java.net.ConnectException: Connection refused: connect
2022-11-15 17:06:01 [test-exchange.test-consumer-channel-2] INFO  o.s.a.r.l.SimpleMessageListenerContainer.killOrRestart - Restarting Consumer@17ea9632: tags=[[]], channel=null, acknowledgeMode=AUTO local queue size=0
2022-11-15 17:06:04 [test-exchange.test-consumer-channel-3] INFO  o.s.a.r.c.CachingConnectionFactory.connectAddresses - Attempting to connect to: [localhost:5673]
2022-11-15 17:06:13 [test-exchange.test-consumer-channel-3] WARN  o.s.a.r.l.SimpleMessageListenerContainer.logConsumerException - Consumer raised exception, processing can restart if the connection factory supports it. Exception summary: org.springframework.amqp.AmqpConnectException: java.net.ConnectException: Connection refused: connect
2022-11-15 17:06:13 [test-exchange.test-consumer-channel-3] INFO  o.s.a.r.l.SimpleMessageListenerContainer.killOrRestart - Restarting Consumer@30dd942a: tags=[[]], channel=null, acknowledgeMode=AUTO local queue size=0
2022-11-15 17:06:16 [test-exchange.test-consumer-channel-4] INFO  o.s.a.r.c.CachingConnectionFactory.connectAddresses - Attempting to connect to: [localhost:5673]

Answer 1

You are actually describing the feature of spring-cloud-stream (SCSt) where the binder automatically connects/reconnects to the server, thus making your app resilient.

Sure, we can add some kind of switch to stop reconnecting, but what would that buy you? SCSt is not for generic messaging apps (there are other spring frameworks for that). It was specifically designed for data streaming cases, where connection may be disrupted but the system stays resilient. There is really no valid use case for streaming application to sit in an un-connected state. . . then it is not a streaming application.