Actuator RabbitMQ cannot report the status properly if not binded

[christophe-f]

Hi,

My app is connecting to RabbitMQ thru the settings coming from a config server. The app is working fine but the actuator endpoints reports:

status:DOWN
binders
  status:UP
  rabbit-primary
    status:UP
    binderHealthIndicator
      status:UP
      version:3.5.8
rabbit
  status:DOWN
  error:org.springframework.amqp.AmqpConnectException: java.net.ConnectException: Connection refused (Connection refused)

After creating a service and binding it to the app, the status is fine:

status:UP
binders
  status:UP
  rabbit-primary
    status:UP
    binderHealthIndicator
      status:UP
      version:3.5.8
rabbit
  status:UP

I'm using the latest Springboot 1.5.9 version and run on PWS.

I know it's better to be able to bind to a service, but in reality it won't be always the case.

Thanks

[philwebb]

settings coming from a config server

Can you share an example of these settings? Are you able to reproduce the issue without the config server involved and share a sample?

[christophe-f]

Hi Phil,

Here is a sample at https://github.com/christophe-f/rabbitmq-actuator-sample

You can replace line 11 in application.yml with your own settings to be able to reproduce.

[wilkinsona]

Thanks for the sample, @christophe-f.

The problem here is that Spring Cloud Streams Rabbit binder provides the necessary dependencies for Boot's RabbitAutoConfiguration to be enabled. spring.rabbitmq.host and spring.rabbitmq.port haven't been configured so the auto-configured connection factory tries to connect to localhost:5672 and is unable to do so. As a result, RabbitHealthIndicator reports that Rabbit is down. The problem does a way on PWS when the application is bound to a Rabbit service as this replaces the auto-configured connection factory with one that can connect to the bound service.

I'm not sure what we can do here as we have no way of interpreting the user's intent. It could be any of the following:

1. They are using Spring Cloud Stream's Rabbit binder and don't care that the auto-configured connection factory is unusable.
2. They are using Spring Cloud Stream's Rabbit binder and also want to use the auto-configured connection factory but forgot to bind a service when deploying to PWS.
3. They aren't using Spring Cloud Stream, want to use the auto-configured connection factory, and forgot to bind a service when deploying to PWS.
4. They don't care about Rabbit it all but the dependencies are on the classpath anyway for some reason

For 2, 3, and 4, it's beneficial that the health indicator reports that Rabbit is down as there is a problem of some sort. For 1, the ideal would be that the health indicator doesn't report that Rabbit is down. However, I don't think that's possible as we can't distinguish between scenario 1 and scenario 2.

@christophe-f Given that you've opted to provide binder-specific Rabbit configuration and don't, as far as I can tell, care about Boot's auto-configured Rabbit connection factory and template, I think you have two options:

1. If, as shown in your sample, you only have a single binder, move your Rabbit configuration so that it's not binder-specific
2. Exclude Spring Boot's RabbitMqAutoConfiguration

If neither of these options are suitable, please let us know and we'll probably need to talk to the SCS team to see what an alternative might be.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.