Skip to content

Commit ba4b62e

Browse files
committed
GH-1449: Fix Auto Recovery Docs
Resolves #1449
1 parent f2717a1 commit ba4b62e

1 file changed

Lines changed: 6 additions & 8 deletions

File tree

src/reference/asciidoc/amqp.adoc

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -987,14 +987,12 @@ image::images/cacheStats.png[align="center"]
987987
Since the first version of Spring AMQP, the framework has provided its own connection and channel recovery in the event of a broker failure.
988988
Also, as discussed in <<broker-configuration>>, the `RabbitAdmin` re-declares any infrastructure beans (queues and others) when the connection is re-established.
989989
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.
990-
Spring AMQP now uses the `4.0.x` version of `amqp-client`, which has auto recovery enabled by default.
991-
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`).
992-
However, the framework is completely compatible with auto-recovery being enabled.
993-
This means any consumers you create within your code (perhaps via `RabbitTemplate.execute()`) can be recovered automatically.
990+
The `amqp-client`, has auto recovery enabled by default.
991+
There are some incompatibilities between the two recovery mechanisms so, by default, Spring sets the `automaticRecoveryEnabled` property on the underlying `RabbitMQ connectionFactory` to `false`.
992+
Even if the property is `true`, Spring effectively disables it, by immediately closing any recovered connections.
994993

995-
IMPORTANT: Only elements (queues, exchanges, bindings) that are defined as beans will be re-declared after a connection failure.
996-
Elements declared by invoking `RabbitAdmin.declare*()` methods directly from user code are unknown to the framework and therefore cannot be recovered.
997-
If you have a need for a variable number of declarations, consider defining a bean, or beans, of type `Declarables`, as discussed in <<collection-declaration>>.
994+
IMPORTANT: By default, only elements (queues, exchanges, bindings) that are defined as beans will be re-declared after a connection failure.
995+
See <<declarable-recovery>> for how to change that behavior.
998996

999997
[[custom-client-props]]
1000998
==== Adding Custom Client Connection Properties
@@ -5405,7 +5403,7 @@ Normally, the `RabbitAdmin` (s) only recover queues/exchanges/bindings that are
54055403
When the connection is re-established, the admin will redeclare the entities.
54065404
Normally, entities created by calling `admin.declareQueue(...)`, `admin.declareExchange(...)` and `admin.declareBinding(...)` will not be recovered.
54075405

5408-
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.
5406+
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.
54095407

54105408
Recovery of individual declarations will not be performed if `deleteQueue(...)`, `deleteExchange(...)` or `removeBinding(...)` is called.
54115409
Associated bindings are removed from the recoverable entities when queues and exchanges are deleted.

0 commit comments

Comments
 (0)