0

I see that my custom Spring cloud stream sink with log sink stream app dependency loses RabbitMQ connectivity during RabbitMQ outage, tries making a connection for 5 times and then stops its consumer. I have to manually restart the app to make it successfully connect once the RabbitMQ is up. When I see the default properties of rabbitMQ binding here, it gives interval time but there is no property for infinite retry(which i assume to be default behaviour). Can someone please let me know what I might be missing here to make it try connecting infinitely ? 

Error faced during outage triggering consumer retry :
2017-08-08T10:52:07.586-04:00 [APP/PROC/WEB/0] [OUT] Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=404, reply-text=NOT_FOUND - home node 'rabbit@229ec9f90e07c75d56a0aa84dc28f602' of durable queue 'datastream.dataingestor.datastream' in vhost '8880756f-8a21-4dc8-9b97-95e5a3248f58' is down or inaccessible, class-id=50, method-id=10)
rahul
  • 71
  • 1
  • 1
  • 7
  • I'm getting similar issue after 3 times, not 5. Apparently this is the default value from `SimpleMessageListenerContainer` (https://docs.spring.io/spring-amqp/docs/1.7.4.RELEASE/reference/htmlsingle/#containerAttributes). Are you overriding this number somehow? – L. Holanda Oct 24 '17 at 00:11

1 Answers1

0

It appears you have a RabbitMQ cluster and the queue in question is hosted on a down node.

If the queue was HA, you wouldn't have this problem.

The listener container does not (currently) handle that condition. It will retry for ever if it loses connection to RabbitMQ itself.

Please open a JIRA Issue and we'll take a look. The container should treat that error the same as a connection problem.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • I opened [this JIRA](https://jira.spring.io/browse/AMQP-778) having reproduced the issue with a simple Spring AMQP app. – Gary Russell Oct 23 '17 at 20:18
  • Hi @GaryRussel, looking at `SimpleMessageListenerContainer`'s `missingQueuesFatal` seems like this would be the way to solve this connectivity issue. I'm also having similar problem as @rahul is having. Is this related to the JIRA you have opened? Would you recommend a workaround until JIRA is fixed? I tried to declare my own `SimpleMessageListenerContainer` beans but binder seems to ignore the bean and call constructor directly. Also, SimpleMessageListenerContainer.checkMissingQueuesFatal() doesn't seem to load `spring.amqp.global.properties` as `applicationContext` is always null. – L. Holanda Oct 24 '17 at 00:12
  • 1
    Yes; `missingQueuesFatal=false` would work; unfortunately, it's not exposed by the binder; I closed the JIRA since we can solve the issue by exposing more properties in the binder - see [#104](https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/104). – Gary Russell Oct 24 '17 at 12:37