You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by ur...@apache.org on 2022/05/24 06:06:02 UTC
[pulsar-site] branch main updated: Docs sync done from apache/pulsar(#b155d84)
This is an automated email from the ASF dual-hosted git repository.
urfree pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/pulsar-site.git
The following commit(s) were added to refs/heads/main by this push:
new cfa07ab33c3 Docs sync done from apache/pulsar(#b155d84)
cfa07ab33c3 is described below
commit cfa07ab33c3ba7f7a1ff611f42bb12caa97e2224
Author: Pulsar Site Updater <de...@pulsar.apache.org>
AuthorDate: Tue May 24 06:05:56 2022 +0000
Docs sync done from apache/pulsar(#b155d84)
---
site2/website-next/docs/develop-binary-protocol.md | 8 ++++++
.../docs/developing-binary-protocol.md | 14 +++++++++-
.../docs/schema-evolution-compatibility.md | 32 +++++++++++-----------
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/site2/website-next/docs/develop-binary-protocol.md b/site2/website-next/docs/develop-binary-protocol.md
index 63e43dda525..ce72beacf70 100644
--- a/site2/website-next/docs/develop-binary-protocol.md
+++ b/site2/website-next/docs/develop-binary-protocol.md
@@ -4,6 +4,14 @@ title: Pulsar binary protocol specification
sidebar_label: "Binary protocol"
---
+:::note
+
+**Important**
+
+This page is deprecated and not updated anymore. For the latest and complete information, see [Pulsar binary protocol specification](developing-binary-protocol.md).
+
+:::
+
Pulsar uses a custom binary protocol for communications between producers/consumers and brokers. This protocol is designed to support required features, such as acknowledgements and flow control, while ensuring maximum transport and implementation efficiency.
Clients and brokers exchange *commands* with each other. Commands are formatted as binary [protocol buffer](https://developers.google.com/protocol-buffers/) (aka *protobuf*) messages. The format of protobuf commands is specified in the [`PulsarApi.proto`](https://github.com/apache/pulsar/blob/master/pulsar-common/src/main/proto/PulsarApi.proto) file and also documented in the [Protobuf interface](#protobuf-interface) section below.
diff --git a/site2/website-next/docs/developing-binary-protocol.md b/site2/website-next/docs/developing-binary-protocol.md
index 2c228f623dc..d571e976b21 100644
--- a/site2/website-next/docs/developing-binary-protocol.md
+++ b/site2/website-next/docs/developing-binary-protocol.md
@@ -191,6 +191,12 @@ If the client does not receive a response indicating producer creation success o
the client should first send a command to close the original producer before sending a
command to re-attempt producer creation.
+:::note
+
+Before creating or connecting a producer, you need to perform [topic lookup](#topic-lookup) first.
+
+:::
+
##### Command Producer
```protobuf
@@ -284,7 +290,7 @@ Fields:
* `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
+ and `entryId`, which reflects that this unique ID is assigned when appending
to a BookKeeper ledger.
@@ -321,6 +327,12 @@ subscription is not already there, a new one will be created.
+:::note
+
+Before creating or connecting a consumer, you need to perform [topic lookup](#topic-lookup) first.
+
+:::
+
#### Flow control
After the consumer is ready, the client needs to *give permission* to the
diff --git a/site2/website-next/docs/schema-evolution-compatibility.md b/site2/website-next/docs/schema-evolution-compatibility.md
index faddc45e596..881180711e5 100644
--- a/site2/website-next/docs/schema-evolution-compatibility.md
+++ b/site2/website-next/docs/schema-evolution-compatibility.md
@@ -96,10 +96,10 @@ Suppose that you have a topic containing three schemas (V1, V2, and V3), V1 is t
Suppose that you have a topic containing three schemas (V1, V2, and V3), V1 is the oldest and V3 is the latest:
-| Compatibility check strategy | Definition | Description |
-|---|---|---|
-`BACKWARD` | Consumers using the new schema can process data written by producers using the **last schema**. | The consumers using the schema V3 can process data written by producers using the schema V3 or V2. |
-`BACKWARD_TRANSITIVE` | Consumers using the new schema can process data written by producers using **all previous schemas**. | The consumers using the schema V3 can process data written by producers using the schema V3, V2, or V1. |
+| Compatibility check strategy | Definition | Description |
+|------------------------------|------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
+| `BACKWARD` | Consumers using the new schema can process data written by producers using the **last schema**. | The consumers using the schema V3 can process data written by producers using the schema V3 or V2. |
+| `BACKWARD_TRANSITIVE` | Consumers using the new schema can process data written by producers using **all previous schemas**. | The consumers using the schema V3 can process data written by producers using the schema V3, V2, or V1. |
#### Example
@@ -119,10 +119,10 @@ Suppose that you have a topic containing three schemas (V1, V2, and V3), V1 is t
Suppose that you have a topic containing three schemas (V1, V2, and V3), V1 is the oldest and V3 is the latest:
-| Compatibility check strategy | Definition | Description |
-|---|---|---|
-`FORWARD` | Consumers using the **last schema** can process data written by producers using a new schema, even though they may not be able to use the full capabilities of the new schema. | The consumers using the schema V3 or V2 can process data written by producers using the schema V3. |
-`FORWARD_TRANSITIVE` | Consumers using **all previous schemas** can process data written by producers using a new schema. | The consumers using the schema V3, V2, or V1 can process data written by producers using the schema V3.
+| Compatibility check strategy | Definition | Description |
+|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
+| `FORWARD` | Consumers using the **last schema** can process data written by producers using a new schema, even though they may not be able to use the full capabilities of the new schema. | The consumers using the schema V3 or V2 can process data written by producers using the schema V3. |
+| `FORWARD_TRANSITIVE` | Consumers using **all previous schemas** can process data written by producers using a new schema. | The consumers using the schema V3, V2, or V1 can process data written by producers using the schema V3. |
#### Example
@@ -155,7 +155,7 @@ In some data formats, for example, Avro, you can define fields with default valu
:::tip
-You can set schema compatibility check strategy at the topic, namespace or broker level. For how to set the strategy, see [here](schema-manage.md/#set-schema-compatibility-check-strategy).
+You can set schema compatibility check strategy at the topic, namespace or broker level. For how to set the strategy, see [here](schema-manage.md#set-schema-compatibility-check-strategy).
:::
@@ -193,13 +193,13 @@ The order of upgrading client applications is determined by the compatibility ch
For example, the producers using schemas to write data to Pulsar and the consumers using schemas to read data from Pulsar.
-| Compatibility check strategy | Upgrade first | Description |
-| --- | --- | --- |
-| `ALWAYS_COMPATIBLE` | Any order | The compatibility check is disabled. Consequently, you can upgrade the producers and consumers in **any order**. |
-| `ALWAYS_INCOMPATIBLE` | None | The schema evolution is disabled. |
-| <li>`BACKWARD` </li><li>`BACKWARD_TRANSITIVE` </li> | Consumers | There is no guarantee that consumers using the old schema can read data produced using the new schema. Consequently, **upgrade all consumers first**, and then start producing new data. |
-| <li>`FORWARD` </li><li>`FORWARD_TRANSITIVE` </li> | Producers | There is no guarantee that consumers using the new schema can read data produced using the old schema. Consequently, **upgrade all producers first**<li>to use the new schema and ensure that the data already produced using the old schemas are not available to consumers, and then upgrade the consumers. </li> |
-| <li>`FULL` </li><li>`FULL_TRANSITIVE` </li> | Any order | There is no guarantee that consumers using the old schema can read data produced using the new schema and consumers using the new schema can read data produced using the old schema. Consequently, you can upgrade the producers and consumers in **any order**. |
+| Compatibility check strategy | Upgrade first | Description |
+| --- | --- |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `ALWAYS_COMPATIBLE` | Any order | The compatibility check is disabled. Consequently, you can upgrade the producers and consumers in **any order**. |
+| `ALWAYS_INCOMPATIBLE` | None | The schema evolution is disabled. |
+| <li>`BACKWARD` </li><li>`BACKWARD_TRANSITIVE` </li> | Consumers | There is no guarantee that consumers using the old schema can read data produced using the new schema. Consequently, **upgrade all consumers first**, and then start producing new data. |
+| <li>`FORWARD` </li><li>`FORWARD_TRANSITIVE` </li> | Producers | There is no guarantee that consumers using the new schema can read data produced using the old schema. Consequently, **upgrade all producers first**<li>to use the new schema and ensure that the data already produced using the old schemas are not available to consumers, and then upgrade the consumers. </li> |
+| <li>`FULL` </li><li>`FULL_TRANSITIVE` </li> | Any order | It is guaranteed that consumers using the old schema can read data produced using the new schema and consumers using the new schema can read data produced using the old schema. Consequently, you can upgrade the producers and consumers in **any order**. |