@@ -346,8 +346,8 @@ The following table sums up the main settings to create a `Producer`:
346346
347347|`name`
348348|The logical name of the producer. Specify a name to enable
349- <<outbound-message-de- deduplication,message de- deduplication>>.
350- |`null` (no de-duplication )
349+ <<outbound-message-deduplication,message deduplication>>.
350+ |`null` (no deduplication )
351351
352352|`batchSize`
353353|The maximum number of messages to accumulate before sending them to the broker.
@@ -357,7 +357,7 @@ The following table sums up the main settings to create a `Producer`:
357357|[[producer-sub-entry-size-configuration-entry]]The number of messages to put in a sub-entry. A sub-entry is one "slot" in a publishing
358358frame, meaning outbound messages are not only batched in publishing frames, but in sub-entries
359359as well. Use this feature to increase throughput at the cost of increased latency and
360- potential duplicated messages even when de-duplication is enabled.
360+ potential duplicated messages even when deduplication is enabled.
361361|1 (meaning no use of sub-entry batching)
362362
363363|`maxUnconfirmedMessages`
@@ -475,8 +475,8 @@ type system. It provides good interoperability, which allows streams
475475to be accessed as AMQP 0-9-1 queues, without data loss.
476476====
477477
478- [[outbound-message-de- deduplication]]
479- ===== Message De-deduplication
478+ [[outbound-message-deduplication]]
479+ ===== Message Deduplication
480480
481481RabbitMQ Stream provides publisher confirms to avoid losing messages: once
482482the broker has persisted a message it sends a confirmation for this message.
@@ -490,9 +490,9 @@ Luckily RabbitMQ Stream can detect and filter out duplicated messages, based
490490on 2 client-side elements: the _producer name_ and the _message publishing ID_.
491491
492492[WARNING]
493- .De-duplication is not guaranteed when using sub-entries batching
493+ .Deduplication is not guaranteed when using sub-entries batching
494494====
495- It is not possible to guarantee de-duplication when
495+ It is not possible to guarantee deduplication when
496496<<producer-sub-entry-size-configuration-entry, sub-entry batching>> is in use.
497497Sub-entry batching is disabled by default and it does not prevent from
498498batching messages in a single publish frame, which can already provide
@@ -502,9 +502,9 @@ very high throughput.
502502====== Setting the Name of a Producer
503503
504504The producer name is set when creating the producer instance, which automatically
505- enables de-duplication :
505+ enables deduplication :
506506
507- .Naming a producer to enable message de-duplication
507+ .Naming a producer to enable message deduplication
508508[source,java,indent=0]
509509--------
510510include::{test-examples}/ProducerUsage.java[tag=producer-with-name]
@@ -518,13 +518,13 @@ will automatically recover and retry outstanding messages. The broker will then
518518filter out messages it has already received and persisted. No more duplicates!
519519
520520[IMPORTANT]
521- .Why setting `confirmTimeout` to 0 when using de-duplication ?
521+ .Why setting `confirmTimeout` to 0 when using deduplication ?
522522====
523- The point of de-duplication is to avoid duplicates when retrying unconfirmed messages.
523+ The point of deduplication is to avoid duplicates when retrying unconfirmed messages.
524524But why retrying in the first place? To avoid _losing_ messages, that is enforcing
525525_at-least-once_ semantics. If the client does not stubbornly retry messages and gives
526526up at some point, messages can be lost, which maps to _at-most-once_ semantics. This
527- is why the de-duplication examples set the
527+ is why the deduplication examples set the
528528<<producer-confirm-timeout-configuration-entry,`confirmTimeout` setting>> to `Duration.ZERO`:
529529to disable the background task that calls the confirmation callback for outstanding
530530messages that time out. This way the client will do its best to retry messages
@@ -539,11 +539,11 @@ stream at the same time.
539539
540540====== Understanding Publishing ID
541541
542- The producer name is only one part of the de-duplication mechanism, the other part
542+ The producer name is only one part of the deduplication mechanism, the other part
543543is the _message publishing ID_. If the producer has a name, the client automatically
544544assigns a publishing ID to each outbound message for the producer. The publishing ID
545545is a strictly increasing sequence, starting at 0 and incremented for each message. The default
546- publishing sequence is good enough for de-duplication , but it is possible to
546+ publishing sequence is good enough for deduplication , but it is possible to
547547assign a publishing ID to each message:
548548
549549.Using an explicit publishing ID
@@ -570,7 +570,7 @@ properties (e.g. `messageId`).
570570[IMPORTANT]
571571.Do not mix client-assigned and custom publishing ID
572572====
573- As soon as a producer name is set, message de-duplication is enabled.
573+ As soon as a producer name is set, message deduplication is enabled.
574574It is then possible to let the producer assign a publishing ID to each
575575message or assign custom publishing IDs. *Do one or the other, not both!*
576576====
0 commit comments