You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Navigate to `Admin` > `Policies` > `Add / update a
469
+
policy`.
470
+
</li>
471
+
<li>
472
+
Enter a policy name (such as "qq-overrides") next to Name, a pattern (such as "^qq\.unlimited") next to
473
+
Pattern, and select what kind of entities (quorum queues in this example) the policy should apply to using the `Apply to`
474
+
drop down.
475
+
</li>
476
+
<li>
477
+
Enter "delivery-limit" for policy argument and -1 for its value in the first line next to
478
+
`Policy`.
479
+
</li>
480
+
<li>
481
+
Click `Add policy`.
482
+
</li>
483
+
</ol>
484
+
</TabItem>
485
+
</Tabs>
486
+
424
487
### Configuring the Limit and Setting Up Dead-Lettering {#position-message-handling-configuring-dlx}
425
488
426
489
Messages that are redelivered more times than the limit allows for will be either dropped (removed) or [dead-lettered](./dlx).
@@ -1110,17 +1173,17 @@ truncated regularly. To be able to truncate a section of the log all messages
1110
1173
in that section needs to be acknowledged. Usage patterns that continuously
1111
1174
[reject or nack](./nack) the same message with the `requeue` flag set to true
1112
1175
could cause the log to grow in an unbounded fashion and eventually fill
1113
-
up the disks. Therefore since RabbitMQ 4.0 a default `delivery-limit` of 20 is always set
1114
-
after which the message will be dropped or dead lettered.
1176
+
up the disks. Therefore since RabbitMQ 4.0 a default `delivery-limit` of 20 is
1177
+
always set after which the message will be dropped or dead lettered.
1115
1178
1116
1179
Messages that are rejected or nacked back to a quorum queue will be
1117
1180
returned to the _back_ of the queue _if_ no [delivery-limit](#poison-message-handling) is set.
1118
-
This avoids
1119
-
the above scenario where repeated re-queues causes the Raft log to grow in an
1120
-
unbounded manner. If a `delivery-limit` is set it will use the original behaviour
1181
+
This avoids the above scenario where repeated re-queues causes the Raft log to grow in an unbounded manner. If a `delivery-limit` is set it will use the original behaviour
1121
1182
of returning the message near the head of the queue.
1122
-
(NB: since 4.0 a delivery-limit will only be unset _if_ a queue was upgraded
1123
-
from a prior version, newly declared queues will always have a default of 20).
1183
+
1184
+
The old unlimited delivery-limit behaviour can be restored by setting a queue
1185
+
argument or policy with a delivery limit of -1. It is not recommended to do
1186
+
so but may be needed for 3.13.x compatibility in some rare cases.
0 commit comments