You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by si...@apache.org on 2021/01/11 02:55:16 UTC
[pulsar] branch master updated: DOCS - Modify the note description
of Key_shared mode (#9160)
This is an automated email from the ASF dual-hosted git repository.
sijie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.git
The following commit(s) were added to refs/heads/master by this push:
new 6d25a41 DOCS - Modify the note description of Key_shared mode (#9160)
6d25a41 is described below
commit 6d25a418d3d21947f79c185ff9418992948fb8ed
Author: Sijia Wang <53...@users.noreply.github.com>
AuthorDate: Mon Jan 11 03:54:44 2021 +0100
DOCS - Modify the note description of Key_shared mode (#9160)
---
site2/docs/concepts-messaging.md | 21 +++++++++--------
.../version-2.6.0/concepts-messaging.md | 26 +++++++++++-----------
.../version-2.6.1/concepts-messaging.md | 24 ++++++++++----------
.../version-2.6.2/concepts-messaging.md | 24 ++++++++++----------
.../version-2.6.3/concepts-messaging.md | 24 ++++++++++----------
.../version-2.7.0/concepts-messaging.md | 24 ++++++++++----------
.../version-2.7.1/concepts-messaging.md | 24 ++++++++++----------
7 files changed, 83 insertions(+), 84 deletions(-)
diff --git a/site2/docs/concepts-messaging.md b/site2/docs/concepts-messaging.md
index 764a977..ae266c5 100644
--- a/site2/docs/concepts-messaging.md
+++ b/site2/docs/concepts-messaging.md
@@ -115,8 +115,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -129,17 +128,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -181,7 +180,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -222,7 +221,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -236,7 +235,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -273,7 +272,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -284,7 +283,7 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
@@ -305,7 +304,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.
diff --git a/site2/website/versioned_docs/version-2.6.0/concepts-messaging.md b/site2/website/versioned_docs/version-2.6.0/concepts-messaging.md
index 7e39b37..b9d19e7 100644
--- a/site2/website/versioned_docs/version-2.6.0/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.6.0/concepts-messaging.md
@@ -92,8 +92,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> #### Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers having access to the same subscription. In the shared subscription mode, messages can be acknowledged individually.
### Negative acknowledgement
@@ -106,17 +105,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages in the same batch may be redelivered to the consumer as well as the negatively acknowledged messages.
### Acknowledgement timeout
When a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client will track the unacknowledged messages within the entire `acktimeout` time range, and send a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages in the same batch may be redelivered to the consumer as well as the unacknowledged messages.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -158,7 +157,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -200,7 +199,7 @@ Topic name component | Description
`topic` | The final part of the name. Topic names are freeform and have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You don't need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar will automatically create that topic under the [namespace](#namespaces) provided in the [topic name](#topics).
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -214,7 +213,7 @@ A subscription is a named configuration rule that determines how messages are de
-> #### Pub-Sub, Queuing, or Both
+> **Pub-Sub, Queuing, or Both**
> There is a lot of flexibility in how to combine subscriptions:
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, you can make each consumer have a unique subscription name (exclusive)
> * If you want to achieve "message queuing" among consumers, you can make multiple consumers have the same subscription name (shared, failover, key_shared)
@@ -248,7 +247,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -259,10 +258,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
-> When using Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> **Limitations of Key_Shared mode**
+> When you use Key_Shared mode, be aware that:
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -279,7 +279,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client will automatically make a call to the Pulsar API to discover the topics that match the regex pattern/list and then subscribe to all of them. If any of the topics don't currently exist, the consumer will auto-subscribe to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
Here are some multi-topic subscription examples for Java:
diff --git a/site2/website/versioned_docs/version-2.6.1/concepts-messaging.md b/site2/website/versioned_docs/version-2.6.1/concepts-messaging.md
index 2dfb7db..dab92f4 100644
--- a/site2/website/versioned_docs/version-2.6.1/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.6.1/concepts-messaging.md
@@ -116,8 +116,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -130,17 +129,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -182,7 +181,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -223,7 +222,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -237,7 +236,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -271,7 +270,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -282,10 +281,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -302,7 +302,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.
diff --git a/site2/website/versioned_docs/version-2.6.2/concepts-messaging.md b/site2/website/versioned_docs/version-2.6.2/concepts-messaging.md
index 922a3a2..74d46ed 100644
--- a/site2/website/versioned_docs/version-2.6.2/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.6.2/concepts-messaging.md
@@ -116,8 +116,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -130,17 +129,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -182,7 +181,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -223,7 +222,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -237,7 +236,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -271,7 +270,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -282,10 +281,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -302,7 +302,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.
diff --git a/site2/website/versioned_docs/version-2.6.3/concepts-messaging.md b/site2/website/versioned_docs/version-2.6.3/concepts-messaging.md
index c666d33..39526d4 100644
--- a/site2/website/versioned_docs/version-2.6.3/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.6.3/concepts-messaging.md
@@ -116,8 +116,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -130,17 +129,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -182,7 +181,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -223,7 +222,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -237,7 +236,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -271,7 +270,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -282,10 +281,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -302,7 +302,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.
diff --git a/site2/website/versioned_docs/version-2.7.0/concepts-messaging.md b/site2/website/versioned_docs/version-2.7.0/concepts-messaging.md
index 4cb4b79..19cb95c 100644
--- a/site2/website/versioned_docs/version-2.7.0/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.7.0/concepts-messaging.md
@@ -116,8 +116,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -130,17 +129,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -182,7 +181,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -223,7 +222,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -237,7 +236,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -274,7 +273,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -285,10 +284,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -305,7 +305,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.
diff --git a/site2/website/versioned_docs/version-2.7.1/concepts-messaging.md b/site2/website/versioned_docs/version-2.7.1/concepts-messaging.md
index 3b8e246..1812214 100644
--- a/site2/website/versioned_docs/version-2.7.1/concepts-messaging.md
+++ b/site2/website/versioned_docs/version-2.7.1/concepts-messaging.md
@@ -116,8 +116,7 @@ Messages can be acknowledged in the following two ways:
- Messages are acknowledged individually. With individual acknowledgement, the consumer needs to acknowledge each message and sends an acknowledgement request to the broker.
- Messages are acknowledged cumulatively. With cumulative acknowledgement, the consumer only needs to acknowledge the last message it received. All messages in the stream up to (and including) the provided message are not re-delivered to that consumer.
-> Note
->
+> **Note**
> Cumulative acknowledgement cannot be used in the [shared subscription mode](#subscription-modes), because the shared subscription mode involves multiple consumers who have access to the same subscription. In the shared subscription mode, messages are acknowledged individually.
### Negative acknowledgement
@@ -130,17 +129,17 @@ In the exclusive and failover subscription modes, consumers only negatively ackn
In the shared and Key_Shared subscription modes, you can negatively acknowledge messages individually.
-> Note
+> **Note**
> If batching is enabled, other messages and the negatively acknowledged messages in the same batch are redelivered to the consumer.
### Acknowledgement timeout
If a message is not consumed successfully, and you want to trigger the broker to redeliver the message automatically, you can adopt the unacknowledged message automatic re-delivery mechanism. Client tracks the unacknowledged messages within the entire `acktimeout` time range, and sends a `redeliver unacknowledged messages` request to the broker automatically when the acknowledgement timeout is specified.
-> Note
+> **Note**
> If batching is enabled, other messages and the unacknowledged messages in the same batch are redelivered to the consumer.
-> Note
+> **Note**
> Prefer negative acknowledgements over acknowledgement timeout. Negative acknowledgement controls the re-delivery of individual messages with more precision, and avoids invalid redeliveries when the message processing time exceeds the acknowledgement timeout.
### Dead letter topic
@@ -182,7 +181,7 @@ Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
Dead letter topic depends on message re-delivery. Messages are redelivered either due to [acknowledgement timeout](#acknowledgement-timeout) or [negative acknowledgement](#negative-acknowledgement). If you are going to use negative acknowledgement on a message, make sure it is negatively acknowledged before the acknowledgement timeout.
-> Note
+> **Note**
> Currently, dead letter topic is enabled only in the shared subscription mode.
### Retry letter topic
@@ -223,7 +222,7 @@ Topic name component | Description
`namespace` | The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
`topic` | The final part of the name. Topic names have no special meaning in a Pulsar instance.
-> #### No need to explicitly create new topics
+> **No need to explicitly create new topics**
> You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the [topic name](#topics) automatically.
> If no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as `persistent://my-tenant/my-namespace/my-topic`. `persistent://my-tenant/my-namespace/my-topic` means the `my-topic` topic is created in the `my-namespace` namespace of the `my-tenant` tenant.
@@ -237,7 +236,7 @@ A subscription is a named configuration rule that determines how messages are de
-> ### Pub-Sub or Queuing
+> **Pub-Sub or Queuing**
> In Pulsar, you can use different subscriptions flexibly.
> * If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is exclusive subscription mode.
> * If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers(shared, failover, key_shared).
@@ -274,7 +273,7 @@ In *shared* or *round robin* mode, multiple consumers can attach to the same sub
In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscribe to the topic, but **Consumer-C-3** and others could as well.
-> #### Limitations of shared mode
+> **Limitations of shared mode**
> When using shared mode, be aware that:
> * Message ordering is not guaranteed.
> * You cannot use cumulative acknowledgment with shared mode.
@@ -285,10 +284,11 @@ In the diagram below, **Consumer-C-1** and **Consumer-C-2** are able to subscrib
In *Key_Shared* mode, multiple consumers can attach to the same subscription. Messages are delivered in a distribution across consumers and message with same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer. When a consumer connected or disconnected will cause served consumer change for some key of message.
-> #### Limitations of Key_Shared mode
+> **Limitations of Key_Shared mode**
> When you use Key_Shared mode, be aware that:
-> * You need to specify a key or orderingKey for messages
+> * You need to specify a key or orderingKey for messages.
> * You cannot use cumulative acknowledgment with Key_Shared mode.
+> * Your producers should disable batching or use a key-based batch builder.
@@ -305,7 +305,7 @@ When a consumer subscribes to a Pulsar topic, by default it subscribes to one sp
When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created.
-> #### No ordering guarantees across multiple topics
+> **No ordering guarantees across multiple topics**
> When a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends message to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.
The following are multi-topic subscription examples for Java.