You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by li...@apache.org on 2022/05/10 07:37:50 UTC
[pulsar] branch master updated: [feature][doc] Add docs for Command AckResponse to historical versions (#15507)
This is an automated email from the ASF dual-hosted git repository.
liuyu 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 7cd4e939d0b [feature][doc] Add docs for Command AckResponse to historical versions (#15507)
7cd4e939d0b is described below
commit 7cd4e939d0b5cd0b0f2f27d7abc73171cc912f19
Author: momo-jun <60...@users.noreply.github.com>
AuthorDate: Tue May 10 15:37:42 2022 +0800
[feature][doc] Add docs for Command AckResponse to historical versions (#15507)
---
site2/docs/developing-binary-protocol.md | 169 +++++++++++----------
.../version-2.10.0/developing-binary-protocol.md | 41 +++--
.../version-2.8.0/developing-binary-protocol.md | 25 ++-
.../version-2.8.1/developing-binary-protocol.md | 26 +++-
.../version-2.8.2/developing-binary-protocol.md | 26 +++-
.../version-2.8.3/developing-binary-protocol.md | 26 +++-
.../version-2.9.0/developing-binary-protocol.md | 26 +++-
.../version-2.9.1/developing-binary-protocol.md | 24 +++
.../version-2.9.2/developing-binary-protocol.md | 26 +++-
9 files changed, 290 insertions(+), 99 deletions(-)
diff --git a/site2/docs/developing-binary-protocol.md b/site2/docs/developing-binary-protocol.md
index 8ad4bd388da..130a54478f4 100644
--- a/site2/docs/developing-binary-protocol.md
+++ b/site2/docs/developing-binary-protocol.md
@@ -21,7 +21,7 @@ Since protobuf doesn't provide any sort of message frame, all messages in the Pu
The Pulsar protocol allows for two types of commands:
1. **Simple commands** that do not carry a message payload.
-2. **Payload commands** that bear a payload that is used when publishing or delivering messages. In payload commands, the protobuf command data is followed by protobuf [metadata](#message-metadata) and then the payload, which is passed in raw format outside of protobuf. All sizes are passed as 4-byte unsigned big endian integers.
+2. **Payload commands** that bear a payload that is used when publishing or delivering messages. In payload commands, the protobuf command data is followed by protobuf [metadata](#message-metadata) and then the payload, which is passed in a raw format outside of protobuf. All sizes are passed as 4-byte unsigned big-endian integers.
> Message payloads are passed in raw format rather than protobuf format for efficiency reasons.
@@ -82,7 +82,7 @@ Message metadata is stored alongside the application-specified payload as a seri
| `publish_time` | Required | The publish timestamp in Unix time (i.e. as the number of milliseconds since January 1st, 1970 in UTC) |
| `properties` | Required | A sequence of key/value pairs (using the [`KeyValue`](https://github.com/apache/pulsar/blob/master/pulsar-common/src/main/proto/PulsarApi.proto#L32) message). These are application-defined keys and values with no special meaning to Pulsar. |
| `replicated_from` | Optional | Indicates that the message has been replicated and specifies the name of the [cluster](reference-terminology.md#cluster) where the message was originally published |
-| `partition_key` | Optional | While publishing on a partition topic, if the key is present, the hash of the key is used to determine which partition to choose. Partition key is used as the message key. |
+| `partition_key` | Optional | While publishing on a partitioned topic, if the key is present, the hash of the key is used to determine which partition to choose. Partition key is used as the message key. |
| `compression` | Optional | Signals that payload has been compressed and with which compression library |
| `uncompressed_size` | Optional | If compression is used, the producer must fill the uncompressed size field with the original payload size |
| `num_messages_in_batch` | Optional | If this message is really a [batch](#batch-messages) of multiple entries, this field must be set to the number of messages in the batch |
@@ -139,13 +139,10 @@ message CommandConnect {
```
Fields:
- * `client_version` → String based identifier. Format is not enforced
- * `auth_method_name` → *(optional)* Name of the authentication plugin if auth
- enabled
- * `auth_data` → *(optional)* Plugin specific authentication data
- * `protocol_version` → Indicates the protocol version supported by the
- client. Broker will not send commands introduced in newer revisions of the
- protocol. Broker might be enforcing a minimum version
+ * `client_version`: String-based identifier. Format is not enforced.
+ * `auth_method_name`: *(optional)* Name of the authentication plugin if auth is enabled.
+ * `auth_data`: *(optional)* Plugin specific authentication data.
+ * `protocol_version`: Indicates the protocol version supported by the client. Broker will not send commands introduced in newer revisions of the protocol. Broker might be enforcing a minimum version.
```protobuf
message CommandConnected {
@@ -155,10 +152,10 @@ message CommandConnected {
```
Fields:
- * `server_version` → String identifier of broker version
- * `protocol_version` → Protocol version supported by the broker. Client
+ * `server_version`: String identifier of broker version.
+ * `protocol_version`: Protocol version supported by the broker. Client
must not attempt to send commands introduced in newer revisions of the
- protocol
+ protocol.
### Keep Alive
@@ -183,7 +180,7 @@ a producer, the broker will first verify that this particular client is
authorized to publish on the topic.
Once the client gets confirmation of the producer creation, it can publish
-messages to the broker, referring to the producer id negotiated before.
+messages to the broker, referring to the producer ID negotiated before.
@@ -201,13 +198,13 @@ message CommandProducer {
}
```
-Parameters:
- * `topic` → Complete topic name to where you want to create the producer on
- * `producer_id` → Client generated producer identifier. Needs to be unique
- within the same connection
- * `request_id` → Identifier for this request. Used to match the response with
- the originating request. Needs to be unique within the same connection
- * `producer_name` → *(optional)* If a producer name is specified, the name will
+Fields:
+ * `topic`: Complete topic name to where you want to create the producer on.
+ * `producer_id`: Client generated producer identifier. Needs to be unique
+ within the same connection.
+ * `request_id`: Identifier for this request. Used to match the response with
+ the originating request. Needs to be unique within the same connection.
+ * `producer_name`: *(optional)* If a producer name is specified, the name will
be used, otherwise the broker will generate a unique name. Generated
producer name is guaranteed to be globally unique. Implementations are
expected to let the broker generate a new producer name when the producer
@@ -225,9 +222,9 @@ message CommandProducerSuccess {
}
```
-Parameters:
- * `request_id` → Original id of the `CreateProducer` request
- * `producer_name` → Generated globally unique producer name or the name
+Fields:
+ * `request_id`: Original ID of the `CreateProducer` request.
+ * `producer_name`: Generated globally unique producer name or the name
specified by the client, if any.
##### Command Send
@@ -246,13 +243,13 @@ message CommandSend {
}
```
-Parameters:
- * `producer_id` → id of an existing producer
- * `sequence_id` → each message has an associated sequence id which is expected
+Fields:
+ * `producer_id`: The ID of an existing producer.
+ * `sequence_id`: Each message has an associated sequence ID which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
- its sequence id.
- * `num_messages` → *(optional)* Used when publishing a batch of messages at
+ acknowledges the effective publishing of messages will refer to it by
+ its sequence ID.
+ * `num_messages`: *(optional)* Used when publishing a batch of messages at
once.
##### Command SendReceipt
@@ -272,18 +269,20 @@ message CommandSendReceipt {
}
```
-Parameters:
- * `producer_id` → id of producer originating the send request
- * `sequence_id` → sequence id of the published message
- * `message_id` → message id assigned by the system to the published message
- Unique within a single cluster. Message id is composed of 2 longs, `ledgerId`
- and `entryId`, that reflect that this unique id is assigned when appending
- to a BookKeeper ledger
+Fields:
+ * `producer_id`: The ID of producer originating the send request.
+ * `sequence_id`: The sequence ID of the published message.
+ * `message_id`: The message ID assigned by the system to the published message
+ Unique within a single cluster. Message ID is composed of 2 longs, `ledgerId`
+ and `entryId`, that reflect that this unique ID is assigned when appending
+ to a BookKeeper ledger.
##### Command CloseProducer
-**Note**: *This command can be sent by either producer or broker*.
+> **Note**
+>
+> This command can be sent by either producer or broker.
When receiving a `CloseProducer` command, the broker will stop accepting any
more messages for the producer, wait until all pending messages are persisted
@@ -337,15 +336,15 @@ message CommandSubscribe {
}
```
-Parameters:
- * `topic` → Complete topic name to where you want to create the consumer on
- * `subscription` → Subscription name
- * `subType` → Subscription type: Exclusive, Shared, Failover, Key_Shared
- * `consumer_id` → Client generated consumer identifier. Needs to be unique
- within the same connection
- * `request_id` → Identifier for this request. Used to match the response with
- the originating request. Needs to be unique within the same connection
- * `consumer_name` → *(optional)* Clients can specify a consumer name. This
+Fields:
+ * `topic`: Complete topic name to where you want to create the consumer on.
+ * `subscription`: Subscription name.
+ * `subType`: Subscription type: Exclusive, Shared, Failover, Key_Shared.
+ * `consumer_id`: Client generated consumer identifier. Needs to be unique
+ within the same connection.
+ * `request_id`: Identifier for this request. Used to match the response with
+ the originating request. Needs to be unique within the same connection.
+ * `consumer_name`: *(optional)* Clients can specify a consumer name. This
name can be used to track a particular consumer in the stats. Also, in
Failover subscription type, the name is used to decide which consumer is
elected as *master* (the one receiving messages): consumers are sorted by
@@ -360,10 +359,10 @@ message CommandFlow {
}
```
-Parameters:
-* `consumer_id` → ID of an already established consumer
-* `messagePermits` → Number of additional permits to grant to the broker for
- pushing more messages
+Fields:
+* `consumer_id`: The ID of an already established consumer.
+* `messagePermits`: The number of additional permits to grant to the broker for
+ pushing more messages.
##### Command Message
@@ -405,28 +404,28 @@ message CommandAck {
}
```
-Parameters:
- * `consumer_id` → ID of an already established consumer
- * `ack_type` → Type of acknowledgment: `Individual` or `Cumulative`
- * `message_id` → ID of the message to acknowledge
- * `validation_error` → *(optional)* Indicates that the consumer has discarded
+Fields:
+ * `consumer_id`: The ID of an already established consumer.
+ * `ack_type`: Acknowledgment type: `Individual` or `Cumulative`.
+ * `message_id`: The ID of the message to acknowledge.
+ * `validation_error`: *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
- `DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
- * `properties` -> *(optional)* Reserved configuration items
- * `txnid_most_bits` -> *(optional)* Same as TC ID, `txnid_most_bits` and `txnid_least_bits`
+ `DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`.
+ * `properties`: *(optional)* Reserved configuration items.
+ * `txnid_most_bits`: *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
uniquely identify a transaction.
- * `txnid_least_bits` -> *(optional)* The ID of the transaction opened in a TC,
+ * `txnid_least_bits`: *(optional)* The ID of the transaction opened in a transaction coordinator,
`txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
- * `request_id` -> *(optional)* ID for handling response and timeout.
+ * `request_id`: *(optional)* The ID for handling response and timeout.
##### Command AckResponse
An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
-If a transaction is used, it contains both Transaction ID and Request ID that are sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request.
The client finishes the specific request according to the Request ID.
If the `error` field is set, it indicates that the request has failed.
-Example of ack response with redirection:
+An example of `AckResponse` with redirection:
```protobuf
message CommandAckResponse {
@@ -439,7 +438,9 @@ message CommandAckResponse {
##### Command CloseConsumer
-***Note***: *This command can be sent by either producer or broker*.
+> **Note**
+>
+> This command can be sent by either producer or broker.
This command behaves the same as [`CloseProducer`](#command-closeproducer)
@@ -448,7 +449,7 @@ This command behaves the same as [`CloseProducer`](#command-closeproducer)
A consumer can ask the broker to redeliver some or all of the pending messages
that were pushed to that particular consumer and not yet acknowledged.
-The protobuf object accepts a list of message ids that the consumer wants to
+The protobuf object accepts a list of message IDs that the consumer wants to
be redelivered. If the list is empty, the broker will redeliver all the
pending messages.
@@ -469,10 +470,11 @@ messages are coming from the consumer.
This command is sent by the client to retrieve Subscriber and Consumer level
stats from the broker.
-Parameters:
- * `request_id` → ID of the request, used to correlate the request
+
+Fields:
+ * `request_id`: The ID of the request, used to correlate the request
and the response.
- * `consumer_id` → ID of an already established consumer.
+ * `consumer_id`: The ID of an already established consumer.
##### Command ConsumerStatsResponse
@@ -483,9 +485,10 @@ If the `error_code` or the `error_message` field is set it indicates that the re
##### Command Unsubscribe
This command is sent by the client to unsubscribe the `consumer_id` from the associated topic.
-Parameters:
- * `request_id` → ID of the request.
- * `consumer_id` → ID of an already established consumer which needs to unsubscribe.
+
+Fields:
+ * `request_id`: The ID of the request.
+ * `consumer_id`: The ID of an already established consumer that needs to unsubscribe.
## Service discovery
@@ -497,11 +500,9 @@ reconnect a producer or a consumer. Lookup is used to discover which particular
broker is serving the topic we are about to use.
Lookup can be done with a REST call as described in the
-[admin API](admin-api-topics.md#lookup-of-topic)
-docs.
+[admin API](admin-api-topics.md#lookup-of-topic) docs.
-Since Pulsar-1.16 it is also possible to perform the lookup within the binary
-protocol.
+Since Pulsar-1.16 it is also possible to perform the lookup within the binary protocol.
For the sake of example, let's assume we have a service discovery component
running at `pulsar://broker.example.com:6650`
@@ -527,15 +528,15 @@ message CommandLookupTopic {
```
Fields:
- * `topic` → Topic name to lookup
- * `request_id` → ID of the request that will be passed with its response
- * `authoritative` → Initial lookup request should use false. When following a
+ * `topic`: The topic name to lookup.
+ * `request_id`: The ID of the request that will be passed with its response.
+ * `authoritative`: Initial lookup request should use false. When following a
redirect response, client should pass the same value contained in the
- response
+ response.
##### LookupTopicResponse
-Example of response with successful lookup:
+An example of response with successful lookup:
```protobuf
message CommandLookupTopicResponse {
@@ -547,7 +548,7 @@ message CommandLookupTopicResponse {
}
```
-Example of lookup response with redirection:
+This is an example of lookup response with redirection:
```protobuf
message CommandLookupTopicResponse {
@@ -575,7 +576,7 @@ suffix.
This information only needs to be retrieved the first time a producer or
consumer is created. There is no need to do this after reconnections.
-The discovery of partitioned topics metadata works very similar to the topic
+The discovery of partitioned topics metadata works very similarly to the topic
lookup. The client send a request to the service discovery address and the
response will contain actual metadata.
@@ -589,13 +590,13 @@ message CommandPartitionedTopicMetadata {
```
Fields:
- * `topic` → the topic for which to check the partitions metadata
- * `request_id` → ID of the request that will be passed with its response
+ * `topic`: The topic for which to check the partitions metadata.
+ * `request_id`: The ID of the request that will be passed with its response.
##### Command PartitionedTopicMetadataResponse
-Example of response with metadata:
+An example of response with metadata:
```protobuf
message CommandPartitionedTopicMetadataResponse {
diff --git a/site2/website/versioned_docs/version-2.10.0/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.10.0/developing-binary-protocol.md
index b215c6b07f2..896d76bac84 100644
--- a/site2/website/versioned_docs/version-2.10.0/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.10.0/developing-binary-protocol.md
@@ -184,7 +184,7 @@ a producer, the broker will first verify that this particular client is
authorized to publish on the topic.
Once the client gets confirmation of the producer creation, it can publish
-messages to the broker, referring to the producer id negotiated before.
+messages to the broker, referring to the producer ID negotiated before.
@@ -227,7 +227,7 @@ message CommandProducerSuccess {
```
Parameters:
- * `request_id` → Original id of the `CreateProducer` request
+ * `request_id` → The original ID of the `CreateProducer` request
* `producer_name` → Generated globally unique producer name or the name
specified by the client, if any.
@@ -248,8 +248,8 @@ message CommandSend {
```
Parameters:
- * `producer_id` → id of an existing producer
- * `sequence_id` → each message has an associated sequence id which is expected
+ * `producer_id` → The ID of an existing producer
+ * `sequence_id` → Each message has an associated sequence ID which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
acknowledges the effective publishing of a messages will refer to it by
its sequence id.
@@ -274,11 +274,11 @@ message CommandSendReceipt {
```
Parameters:
- * `producer_id` → id of producer originating the send request
- * `sequence_id` → sequence id of the published message
- * `message_id` → message id assigned by the system to the published message
- Unique within a single cluster. Message id is composed of 2 longs, `ledgerId`
- and `entryId`, that reflect that this unique id is assigned when appending
+ * `producer_id` → The ID of producer originating the send request
+ * `sequence_id` → The sequence ID of the published message
+ * `message_id` → The message ID assigned by the system to the published message
+ Unique within a single cluster. Message ID is composed of 2 longs, `ledgerId`
+ and `entryId`, that reflect that this unique ID is assigned when appending
to a BookKeeper ledger
@@ -413,6 +413,29 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* The ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.8.0/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.8.0/developing-binary-protocol.md
index 1f59621f13b..164cabc2325 100644
--- a/site2/website/versioned_docs/version-2.8.0/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.8.0/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,29 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.8.1/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.8.1/developing-binary-protocol.md
index 6857a7f4944..545b8da408b 100644
--- a/site2/website/versioned_docs/version-2.8.1/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.8.1/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.8.2/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.8.2/developing-binary-protocol.md
index 2844185ab1a..dd4d591c825 100644
--- a/site2/website/versioned_docs/version-2.8.2/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.8.2/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.8.3/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.8.3/developing-binary-protocol.md
index 242c724574c..29958b02afb 100644
--- a/site2/website/versioned_docs/version-2.8.3/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.8.3/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.9.0/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.9.0/developing-binary-protocol.md
index f7f20cb5591..c9f3529eba8 100644
--- a/site2/website/versioned_docs/version-2.9.0/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.9.0/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.9.1/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.9.1/developing-binary-protocol.md
index e6dd8f41ba2..612db101ef8 100644
--- a/site2/website/versioned_docs/version-2.9.1/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.9.1/developing-binary-protocol.md
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer
diff --git a/site2/website/versioned_docs/version-2.9.2/developing-binary-protocol.md b/site2/website/versioned_docs/version-2.9.2/developing-binary-protocol.md
index 5331b59161e..ffcceab1de7 100644
--- a/site2/website/versioned_docs/version-2.9.2/developing-binary-protocol.md
+++ b/site2/website/versioned_docs/version-2.9.2/developing-binary-protocol.md
@@ -225,7 +225,7 @@ Parameters:
* `producer_id` → id of an existing producer
* `sequence_id` → each message has an associated sequence id which is expected
to be implemented with a counter starting at 0. The `SendReceipt` that
- acknowledges the effective publishing of a messages will refer to it by
+ acknowledges the effective publishing of messages will refer to it by
its sequence id.
* `num_messages` → *(optional)* Used when publishing a batch of messages at
once.
@@ -382,6 +382,30 @@ Parameters:
* `validation_error` → *(optional)* Indicates that the consumer has discarded
the messages due to: `UncompressedSizeCorruption`,
`DecompressionError`, `ChecksumMismatch`, `BatchDeSerializeError`
+ * `properties` → *(optional)* Reserved configuration items
+ * `txnid_most_bits` → *(optional)* Same as Transaction Coordinator ID, `txnid_most_bits` and `txnid_least_bits`
+ uniquely identify a transaction.
+ * `txnid_least_bits` → *(optional)* The ID of the transaction opened in a transaction coordinator,
+ `txnid_most_bits` and `txnid_least_bits`uniquely identify a transaction.
+ * `request_id` → *(optional)* ID for handling response and timeout.
+
+
+ ##### Command AckResponse
+
+An `AckResponse` is the broker’s response to acknowledge a request sent by the client. It contains the `consumer_id` sent in the request.
+If a transaction is used, it contains both the Transaction ID and the Request ID that are sent in the request. The client finishes the specific request according to the Request ID. If the `error` field is set, it indicates that the request has failed.
+
+An example of `AckResponse` with redirection:
+
+```protobuf
+message CommandAckResponse {
+ "consumer_id" : 1,
+ "txnid_least_bits" = 0,
+ "txnid_most_bits" = 1,
+ "request_id" = 5
+}
+```
+
##### Command CloseConsumer