Merge branch 'live' into stable

dumbbell · dumbbell · commit 5d95dbc6023d · 2024-01-30T10:27:54.000+01:00
diff --git a/site/backup.md b/site/backup.md
@@ -113,18 +113,8 @@ copy the messages, skip copying the [message directories](#manual-messages-backu
 
 ### <a id="manual-definitions-restore" class="anchor" href="#manual-definitions-restore">Restoring from a Manual Definitions Backup</a>
 
-Internal node database stores node's name in certain records. Should node name change, the database must first
-be updated to reflect the change using the following [rabbitmqctl](./cli.html) command:
-
-<pre class="lang-sh">
-rabbitmqctl rename_cluster_node &lt;oldnode&gt; &lt;newnode&gt;
-</pre>
-
-The command can take multiple old name/new name pairs if multiple nodes in a cluster are being renamed
-at the same time.
-
-When a new node starts with a backed up directory and a matching node name, it should perform
-the upgrade steps as needed and proceed booting.
+To perform a restore, a new node starts with a backed up directory and the original node name.
+The node then should perform the upgrade steps as needed and proceed booting.
 
 
 ## <a id="messages-backup" class="anchor" href="#messages-backup">Backing Up Messages</a>
diff --git a/site/channels.md b/site/channels.md
@@ -127,6 +127,16 @@ closed.
 
 When a channel's connection is closed, so is the channel.
 
+If a channel is closed immediately after a consumer [acknowledged a number of deliveries](/confirms.html) on it,
+the acknowledgements may or may not reach their target queue before the channel is terminated.
+In this case the messages with a pending acknowledgement on the channel will be automatically requeued
+following the channel closure.
+
+This scenario usually applies to workloads with short lived channels. Using long lived channels and
+designing consumers in a way that they can handle redeliveries potential surprises may be
+associated with this edge case behavior. Note that redelivered messages will be [explicitly marked as such](/consumers.html#message-properties).
+
+
 ### <a id="error-handling" class="anchor" href="#error-handling">Channels and Error Handling</a>
 
 In the section above channels were closed by applications. There is another way a channel can
diff --git a/site/configure.md b/site/configure.md
@@ -1363,14 +1363,14 @@ under the `rabbit` section.
     <td><code>msg_store_file_size_limit</code></td>
     <td>
       Message store segment file size. Changing this for a node
-      with an existing (initialised) database is dangerous can
+      with an existing (initialised) database is dangerous and can
       lead to data loss!
       <p>
         Default: <code>16777216</code>
 <pre class="lang-erlang">
 {rabbit, [
 %% Changing this for a node
-%% with an existing (initialised) database is dangerous can
+%% with an existing (initialised) database is dangerous and can
 %% lead to data loss!
 {msg_store_file_size_limit, 16777216}
 ]}
diff --git a/site/devtools.md b/site/devtools.md
@@ -232,7 +232,7 @@ Miscellaneous projects:
 
 * [Chef RabbitMQ Cookbook](https://github.com/rabbitmq/chef-cookbook)
 * [Puppet RabbitMQ Module](https://github.com/puppetlabs/puppetlabs-rabbitmq)
-* [RabbitMQ Docker image](https://registry.hub.docker.com/_/rabbitmq/)
+* [RabbitMQ Docker image](https://hub.docker.com/_/rabbitmq/)
 * [Kurtosis Starlark package](https://github.com/kurtosis-tech/rabbitmq-package)
 
 ## <a id="database-integration" class="anchor" href="#database-integration">Database Integration</a>
diff --git a/site/download.md b/site/download.md
@@ -20,7 +20,7 @@ limitations under the License.
 The latest [release](https://github.com/rabbitmq/rabbitmq-server/releases) of RabbitMQ is **&version-server;**. See [change log](changelog.html) for release notes.
 See [RabbitMQ support timeline](./versions.html) to find out what release series are supported.
 
-Experimenting with RabbitMQ on your workstation? Try the [community Docker image](https://registry.hub.docker.com/_/rabbitmq/):
+Experimenting with RabbitMQ on your workstation? Try the [community Docker image](https://hub.docker.com/_/rabbitmq/):
 
 <pre class="lang-bash">
 # latest RabbitMQ 3.12
@@ -73,7 +73,7 @@ Other guides related to Kubernetes:
 
 ## Docker
 
- * Docker community-maintained [RabbitMQ Docker image](https://registry.hub.docker.com/_/rabbitmq/) ([on GitHub](https://github.com/docker-library/rabbitmq/))
+ * Docker community-maintained [RabbitMQ Docker image](https://hub.docker.com/_/rabbitmq/) ([on GitHub](https://github.com/docker-library/rabbitmq/))
 
 
 ## Cloud
diff --git a/site/ec2.md b/site/ec2.md
@@ -71,7 +71,7 @@ Please consult the installation guides for
 A wide variety of deployment tools can be used to automate
 RabbitMQ deployment.
 
-  * [Community Docker image](https://registry.hub.docker.com/_/rabbitmq/) ([on GitHub](https://github.com/docker-library/rabbitmq))
+  * [Community Docker image](https://hub.docker.com/_/rabbitmq/) ([on GitHub](https://github.com/docker-library/rabbitmq))
   * [Chef cookbook](https://github.com/rabbitmq/chef-cookbook)
   * [Puppet module](https://github.com/puppetlabs/puppetlabs-rabbitmq)
 
diff --git a/site/getstarted.md b/site/getstarted.md
@@ -22,7 +22,7 @@ applications using RabbitMQ.
 
 You need to have the RabbitMQ server installed to go through
 the tutorials, please see the [installation guide](download.html) or
-use the [Docker image](https://registry.hub.docker.com/_/rabbitmq/).
+use the [Docker image](https://hub.docker.com/_/rabbitmq/).
 
 Executable versions of these tutorials [are open source](https://github.com/rabbitmq/rabbitmq-tutorials),
 as is [this website](https://github.com/rabbitmq/rabbitmq-website).
diff --git a/site/java-tools.md b/site/java-tools.md
@@ -21,22 +21,22 @@ This page documents some Java-based utility programs (PerfTest, Tracer).
 
 ## <a id="load-testing" class="anchor" href="#load-testing">PerfTest</a>
 
-RabbitMQ has a throughput testing tool, PerfTest, that is based on the Java client and can be
+RabbitMQ has a throughput testing tool, [PerfTest](https://github.com/rabbitmq/rabbitmq-perf-test/), that is based on the Java client and can be
 configured to simulate basic and advanced workloads as well.
 
-PerfTest documentation is hosted on GitHub Pages:
+PerfTest Documentation:
 
  * For [the latest stable release](https://perftest.rabbitmq.com/)
- * For [the latest milestone release](https://rabbitmq.github.io/rabbitmq-perf-test/milestone/htmlsingle/)
  * For [the latest development build](https://perftest-dev.rabbitmq.com/)
 
 ## <a id="stream-load-testing" class="anchor" href="#stream-load-testing">PerfTest for Streams (RabbitMQ Stream Protocol)</a>
 
-There is a separate version of PerfTest for streams that uses [RabbitMQ Stream Protocol](./stream.html) internally.
+There is a separate version of [PerfTest for streams](https://github.com/rabbitmq/rabbitmq-stream-perf-test/) that uses [RabbitMQ Stream Protocol](./stream.html) internally.
 
-Its documentation is hosted on GitHub Pages:
+Stream PerfTest Documentation:
 
- * For [the latest stable release](https://rabbitmq.github.io/rabbitmq-stream-java-client/stable/htmlsingle/#the-performance-tool)
+ * For [the latest stable release](https://rabbitmq.github.io/rabbitmq-stream-perf-test/stable/htmlsingle/)
+ * For [the latest development build](https://rabbitmq.github.io/rabbitmq-stream-perf-test/snapshot/htmlsingle/)
 
 
 ## <a id="tracer" class="anchor" href="#tracer">Tracer</a>
diff --git a/site/kubernetes/operator/operator-overview.md b/site/kubernetes/operator/operator-overview.md
@@ -1,4 +1,4 @@
-# &product-name; Kubernetes Operators: Cluster Operator and Message Topology Operator
+# &product-name; Kubernetes Operators: Cluster Operator and Messaging Topology Operator
 
 The RabbitMQ team develop and maintain two [kubernetes operators](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/): the RabbitMQ Cluster Kubernetes Operator and the RabbitMQ Messaging Topology Operator.
 
diff --git a/site/mqtt.md b/site/mqtt.md
@@ -604,6 +604,10 @@ When the Sparkplug support is enabled, the MQTT plugin will not translate the
 
 ## <a id="limitations" class="anchor" href="#limitations">Limitations</a>
 
+### QoS 2 is Not Supported
+
+QoS 2 subscriptions will be treated as if they were QoS 1 subscriptions.
+
 ### Presence of a Quorum of Nodes
 
 See [Consensus Features](#consensus).
diff --git a/site/quorum-queues.md b/site/quorum-queues.md
@@ -151,11 +151,7 @@ no sense in their context. Therefore quorum queues cannot be exclusive.
 
 Quorum queues are not meant to be used as [temporary queues](./queues.html#temporary-queues).
 
-#### TTL (before RabbitMQ 3.10)
-
-Before RabbitMQ 3.10, quorum queues supported [Queue TTL](./ttl.html#queue-ttl), but do not message TTL.
-
-#### TTL (since RabbitMQ 3.10)
+#### Queue and Per-Message TTL (since RabbitMQ 3.10)
 
 Quorum queues support both [Queue TTL](./ttl.html#queue-ttl) and message TTL
 (including [Per-Queue Message TTL in Queues](./ttl.html#per-queue-message-ttl) and
@@ -730,7 +726,7 @@ The following `advanced.config` example modifies all values listed above:
  %% five replicas by default, only makes sense for nine node clusters
  {rabbit, [{quorum_cluster_size, 5},
            {quorum_commands_soft_limit, 512}]}
-]
+].
 </pre>
 
 
@@ -857,4 +853,4 @@ the block device that hosts RabbitMQ node data directory:
 #
 # Sets readahead for device /dev/sda to 4096.
 sudo blockdev --setra 4096 /dev/sda
-</pre>
+</pre>
diff --git a/site/ttl.md b/site/ttl.md
@@ -15,7 +15,17 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-# Time-To-Live and Expiration
+# Time-to-Live and Expiration
+
+Key topics covered in this documentation guide are
+
+ * An overview of queue TTL and message TTL features supported by RabbitMQ
+ * Per-queue [message TTL defined at the queue level](#per-queue-message-ttl)
+ * Per-message [TTL defined by publishers](#per-message-ttl-in-publishers)
+ * [Message TTL and dead lettering](#message-ttl-dead-lettering)
+ * [Message TTL applied retroactively](#message-ttl-applied-retroactively)
+ * [Queue TTL](#queue-ttl) (expiration of queues)
+
 
 ## <a id="overview" class="anchor" href="#overview">Time-To-Live Feature</a>
 
@@ -29,13 +39,10 @@ TTL can also be set on queues, not just queue contents. This feature can be used
 
 Queues will expire after a period of time only when they are not used (a queue is used if it has online consumers).
 
-Expired messages and queues will be deleted.
-
 TTL behavior is controlled by [optional queue arguments](queues.html) and the best way to configure it is using a [policy](./parameters.html).
 
 TTL settings also can be enforced by [operator policies](./parameters.html#operator-policies).
 
-The follow on information in this topic describes how to define message TTL for queues, per-message TTL in publishers, the caveats, and how to define queue TTL.
 
 ## <a id="per-queue-message-ttl" class="anchor" href="#per-queue-message-ttl">Per-Queue Message TTL in Queues</a>
 
@@ -44,14 +51,15 @@ Message TTL can be set for a given queue by setting the
 or by specifying the same argument at the time of queue declaration.
 
 A message that has been in the queue for longer than the configured TTL is said to
-be *dead*. Note that a message routed to multiple queues
-can die at different times, or not at all, in each queue in
+be *expired*. Note that a message routed to multiple queues
+can expire at different times, or not at all, in each queue in
 which it resides. The death of a message in one queue has no
 impact on the life of the same message in other queues.
 
-The server guarantees that dead messages will not be delivered
-using `basic.deliver` (to a consumer) or included into a `basic.get-ok` response
-(for one-off fetch operations).
+The server **guarantees** that expired messages will not be delivered
+using `basic.deliver` (to a consumer) or sent in response to a polling consumer
+(in a `basic.get-ok` response).
+
 Further, the server will try to remove messages at or
 shortly after their TTL-based expiry.
 
@@ -106,7 +114,7 @@ model.QueueDeclare("myqueue", false, false, false, args);
 </pre>
 
 It is possible to apply a message TTL policy to a queue which already
-has messages in it but this involves [some caveats](#per-message-ttl-caveats).
+has messages in it but this involves [some caveats](#per-message-ttl-applied-retroactively).
 
 The original expiry time of a message is preserved if it
 is requeued (for example due to the use of an AMQP method
@@ -121,6 +129,7 @@ the RabbitMQ server does not support. Unlike that flag, no
 `basic.return`s are issued, and if a dead letter
 exchange is set then messages will be dead-lettered.
 
+
 ## <a id="per-message-ttl-in-publishers" class="anchor" href="#per-message-ttl-in-publishers">Per-Message TTL in Publishers</a>
 
 A TTL can be specified on a per-message basis, by setting the
@@ -159,13 +168,42 @@ model.BasicPublish(exchangeName,
                    routingKey, props,
                    messageBodyBytes);</pre>
 
-## <a id="per-message-ttl-caveats" class="anchor" href="#per-message-ttl-caveats">Caveats</a>
+
+## <a id="message-ttl-dead-lettering" class="anchor" href="#message-ttl-dead-lettering">Per-Message TTL and Dead Lettering</a>
+
+For queues that have [dead-lettering configured](./dlx.html), it is important to understand
+when message expiration and dead lettering kick in for every queue type. Since
+queue types have different design goals and implementations, they drop
+expired messages (or dead letter them) under different conditions.
+
+### Quorum Queues
+
+[Quorum queues](./quorum-queues.html) dead letter expired messages shortly after message expiration.
+"Shortly after" here means that the process of dead-lettering, that is,
+republishing to the configured [DLX](./dlx.html), happens concurrently with
+other queue activity and does not await the moment when the expired
+message reaches the head of the queue.
+
+Note that **overall system load** and the **volume of expired messages**
+can affect how long it might take for deadl lettering prcedure to start
+and to to complete.
+
+### Classic Queues
+
+Classic queues dead letter expired messages in a few cases:
+
+ * When message reaches queue head
+ * When the queue is notified of a policy change that affects it
+
+
+## <a id="message-ttl-applied-retroactively" class="anchor" href="#message-ttl-applied-retroactively">Per-message TTL Applied Retroactively (to an Existing Queue)</a>
 
 Queues that had a per-message TTL applied to them
 retroactively (when they already had messages) will discard
-the messages when specific events occur. Only when expired
-messages reach the head of a queue will they actually be
-discarded (or dead-lettered). Consumers will not have
+the messages when specific events occur.
+
+Only when expired messages reach the head of a queue will they actually be
+discarded (marked for deletion). Consumers will not have
 expired messages delivered to them. Keep in mind that
 there can be a natural race condition between message expiration
 and consumer delivery, e.g. a message can expire

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-# &product-name; Kubernetes Operators: Cluster Operator and Message Topology Operator`
	`1`	`+# &product-name; Kubernetes Operators: Cluster Operator and Messaging Topology Operator`
`2`	`2`
`3`	`3`	`The RabbitMQ team develop and maintain two [kubernetes operators](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/): the RabbitMQ Cluster Kubernetes Operator and the RabbitMQ Messaging Topology Operator.`
`4`	`4`