From e8f12b215638699e7f0e59b2a3772b9dad00ca02 Mon Sep 17 00:00:00 2001 From: Gary Russell Date: Tue, 6 Sep 2022 15:15:11 -0400 Subject: [PATCH] GH-1449: Fix Auto Recovery Docs Resolves https://github.com/spring-projects/spring-amqp/issues/1449 --- src/reference/asciidoc/amqp.adoc | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/reference/asciidoc/amqp.adoc b/src/reference/asciidoc/amqp.adoc index 50328bf2..f35f18ae 100644 --- a/src/reference/asciidoc/amqp.adoc +++ b/src/reference/asciidoc/amqp.adoc @@ -986,14 +986,12 @@ image::images/cacheStats.png[align="center"] Since the first version of Spring AMQP, the framework has provided its own connection and channel recovery in the event of a broker failure. Also, as discussed in <>, the `RabbitAdmin` re-declares any infrastructure beans (queues and others) when the connection is re-established. It therefore does not rely on the https://www.rabbitmq.com/api-guide.html#recovery[auto-recovery] that is now provided by the `amqp-client` library. -Spring AMQP now uses the `4.0.x` version of `amqp-client`, which has auto recovery enabled by default. -Spring AMQP can still use its own recovery mechanisms if you wish, disabling it in the client, (by setting the `automaticRecoveryEnabled` property on the underlying `RabbitMQ connectionFactory` to `false`). -However, the framework is completely compatible with auto-recovery being enabled. -This means any consumers you create within your code (perhaps via `RabbitTemplate.execute()`) can be recovered automatically. +The `amqp-client`, has auto recovery enabled by default. +There are some incompatibilities between the two recovery mechanisms so, by default, Spring sets the `automaticRecoveryEnabled` property on the underlying `RabbitMQ connectionFactory` to `false`. +Even if the property is `true`, Spring effectively disables it, by immediately closing any recovered connections. -IMPORTANT: Only elements (queues, exchanges, bindings) that are defined as beans will be re-declared after a connection failure. -Elements declared by invoking `RabbitAdmin.declare*()` methods directly from user code are unknown to the framework and therefore cannot be recovered. -If you have a need for a variable number of declarations, consider defining a bean, or beans, of type `Declarables`, as discussed in <>. +IMPORTANT: By default, only elements (queues, exchanges, bindings) that are defined as beans will be re-declared after a connection failure. +See <> for how to change that behavior. [[custom-client-props]] ==== Adding Custom Client Connection Properties @@ -5483,7 +5481,7 @@ Normally, the `RabbitAdmin` (s) only recover queues/exchanges/bindings that are When the connection is re-established, the admin will redeclare the entities. Normally, entities created by calling `admin.declareQueue(...)`, `admin.declareExchange(...)` and `admin.declareBinding(...)` will not be recovered. -Starting with version 2.4, the admin has a new property `redeclareManualDeclarations`; when true, the admin will recover these entities in addition to the beans in the application context. +Starting with version 2.4, the admin has a new property `redeclareManualDeclarations`; when `true`, the admin will recover these entities in addition to the beans in the application context. Recovery of individual declarations will not be performed if `deleteQueue(...)`, `deleteExchange(...)` or `removeBinding(...)` is called. Associated bindings are removed from the recoverable entities when queues and exchanges are deleted.