Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/128
The binder incorrectly shuts down the connection factory `@Bean`, before the bindings
are stopped, preventing the container waiting for tasks to complete.
Code was added to destroy the CF in the case where we create one locally, which is
correct, but we should not destroy the CF managed by Spring.
Also see https://jira.spring.io/browse/AMQP-800
(cherry picked from commit eaad4d9)
When we don't specify the `host` property for the
`CachingConnectionFactory`, it is selected by the
`InetAddress.getLocalHost().getHostName()`, which might not be
"localhost" as it is allowed for the `guest` user on RabbitMQ.
This also may cause some unexpected loop-backs on the network interface
during connection attempt
**Cherry-pick to 1.3.x**
The Spring Boot's `RabbitProperties` populates the `host:port`
(default values) to the addresses property in the `determineAddresses()`.
This way we override provided by Cloud Connectors `host:port`
* Do not populated `addresses` to the CCF from the `RabbitProperties`
if the real `addresses` is null.
Only explicit `spring.rabbitmq.addresses` application property will have
effect
**Cherry-pick to 1.3.x**
The SC-Connectors `ServiceConnector` can be customized via
`ServiceConnectorConfig`.
* Allow end-user to specify such a bean and support its injection in the
`rabbitConnectionFactory` and `producerConnectionFactory` bean definitions
**Cherry-pick to 1.3.x**
Add `spring-cloud-spring-service-connector` dependency to be able to
request from the application context only specific `RabbitConnectionFactoryConfig`.
Use `ObjectProvider.getIfUnique()` for the case when we have not a single
`RabbitConnectionFactoryConfig` bean in the ctx
* Configure Cloud CCF via Boot's `RabbitProperties`
* Obtain from the Cloud only one CF service
The `RabbitMessageChannelBinder` creates an internal distinct
`ConnectionFactory` instance based on the `RabbitProperties` for the
non-transactional producers to avoid dead locks when connection
is blocked.
In case of Cloud Connectors the `ConnectionFactory` bean is overridden,
but not `RabbitProperties`.
Therefore the original `ConnectionFactory` for consumers is good,
cloud-based, but for producers it is still based on the `RabbitProperties`
from Spring Boot, in most cases with default options.
* Add one more `producerConnectionFactory` `@Bean` to the
`CloudConnectors` configuration to obtain a distinct `ConnectionFactory`
instance from the cloud provider
* When we ara not in the cloud profile, create a fresh `ConnectionFactory`
based on the `RabbitProperties`
* Inject the extra `producerConnectionFactory` instance into the
`RabbitMessageChannelBinder` instead of the internal non-stable solution
**Cherry-pick to 1.3.x**
Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/83
Expressions for the routing key and delay (when using a delayed exhange) that
include the `payload` failed because they were evaluated after the payload was
serialized.
If either expression includes `payload`, add an interceptor to evaluate the expressions
before serialization and add the results as headers.
Polish tests
Resolves#83Resolves#111
Resolves https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/104
To handle the use case of a Rabbit cluster with non-HA queues where the node hosting
a queue is down, set `missingQueuesFatal` to `false` by default.
Expose this property in the consumer config, together with the redeclaration retry properties.
Docs
