Polish

src/reference/antora/modules/ROOT/pages/amqp/containerAttributes.adoc

@@ -435,7 +435,7 @@ a|
 (mismatched-queues-fatal)
 
 a|When the container starts, if this property is `true` (default: `false`), the container checks that all queues declared in the context are compatible with queues already on the broker.
-If mismatched properties (such as `auto-delete`) or arguments (skuch as `x-message-ttl`) exist, the container (and application context) fails to start with a fatal exception.
+If mismatched properties (such as `auto-delete`) or arguments (such as `x-message-ttl`) exist, the container (and application context) fails to start with a fatal exception.
 
 If the problem is detected during recovery (for example, after a lost connection), the container is stopped.
 

src/reference/antora/modules/ROOT/pages/amqp/receiving-messages/async-annotation-driven/error-handling.adoc

@@ -36,7 +36,7 @@ If you use JSON, consider using an `errorHandler` to return some other Jackson-f
 
 IMPORTANT: In version 2.1, this interface moved from package `o.s.amqp.rabbit.listener` to `o.s.amqp.rabbit.listener.api`.
 
-Starting with version 2.1.7, the `Channel` is available in a messaging message header; this allows you to ack or nack the failed messasge when using `AcknowledgeMode.MANUAL`:
+Starting with version 2.1.7, the `Channel` is available in a messaging message header; this allows you to ack or nack the failed message when using `AcknowledgeMode.MANUAL`:
 
 [source, java]
 ----

src/reference/antora/modules/ROOT/pages/amqp/template.adoc

@@ -195,7 +195,7 @@ In general, this means that only one confirm is outstanding on a channel at a ti
 NOTE: Starting with version 2.2, the callbacks are invoked on one of the connection factory's `executor` threads.
 This is to avoid a potential deadlock if you perform Rabbit operations from within the callback.
 With previous versions, the callbacks were invoked directly on the `amqp-client` connection I/O thread; this would deadlock if you perform some RPC operation (such as opening a new channel) since the I/O thread blocks waiting for the result, but the result needs to be processed by the I/O thread itself.
-With those versions, it was necessary to hand off work (such as sending a messasge) to another thread within the callback.
+With those versions, it was necessary to hand off work (such as sending a message) to another thread within the callback.
 This is no longer necessary since the framework now hands off the callback invocation to the executor.
 
 IMPORTANT: The guarantee of receiving a returned message before the ack is still maintained as long as the return callback executes in 60 seconds or less.