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/06/09 12:07:38 UTC
[pulsar-site] branch main updated: Docs sync done from apache/pulsar(#8f40dc9)
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 30b8b7fb20a Docs sync done from apache/pulsar(#8f40dc9)
30b8b7fb20a is described below
commit 30b8b7fb20a077e4adb80fb4e218779e65bb30a3
Author: Pulsar Site Updater <de...@pulsar.apache.org>
AuthorDate: Thu Jun 9 12:07:33 2022 +0000
Docs sync done from apache/pulsar(#8f40dc9)
---
site2/website-next/docs/concepts-messaging.md | 32 ++++++++++++++++++++++
site2/website-next/docs/concepts-multi-tenancy.md | 16 ++++++-----
.../system-topic-for-topic-level-policies.svg | 1 +
.../version-2.10.0/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.10.0/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.8.0/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.8.0/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.8.1/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.8.1/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.8.2/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.8.2/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.8.3/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.8.3/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.9.0/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.9.0/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.9.1/concepts-messaging.md | 32 ++++++++++++++++++++++
.../version-2.9.1/concepts-multi-tenancy.md | 22 ++++++++++-----
.../version-2.9.2/concepts-messaging.md | 31 +++++++++++++++++++++
.../version-2.9.2/concepts-multi-tenancy.md | 22 ++++++++++-----
19 files changed, 417 insertions(+), 63 deletions(-)
diff --git a/site2/website-next/docs/concepts-messaging.md b/site2/website-next/docs/concepts-messaging.md
index f44bb8070a1..79da84c7293 100644
--- a/site2/website-next/docs/concepts-messaging.md
+++ b/site2/website-next/docs/concepts-messaging.md
@@ -857,6 +857,38 @@ Producer<byte[]> producer = client.newProducer()
```
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics. To list system topics, you can add the option `--include-system-topic` when you get the topic list by using [Pulsar admin API](/tools/pulsar-admin).
+
+* Since Pulsar version 2.11.0, system topics are enabled by default.
+ In earlier versions, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file to enable system topics.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
## Message redelivery
Apache Pulsar supports graceful failure handling and ensures critical data is not lost. Software will always have unexpected conditions and at times messages may not be delivered successfully. Therefore, it is important to have a built-in mechanism that handles failure, particularly in asynchronous messaging as highlighted in the following examples.
diff --git a/site2/website-next/docs/concepts-multi-tenancy.md b/site2/website-next/docs/concepts-multi-tenancy.md
index f40f542ecc5..ae8effc9dd4 100644
--- a/site2/website-next/docs/concepts-multi-tenancy.md
+++ b/site2/website-next/docs/concepts-multi-tenancy.md
@@ -45,14 +45,16 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
diff --git a/site2/website-next/static/assets/system-topic-for-topic-level-policies.svg b/site2/website-next/static/assets/system-topic-for-topic-level-policies.svg
new file mode 100644
index 00000000000..85d1f2cfdd3
--- /dev/null
+++ b/site2/website-next/static/assets/system-topic-for-topic-level-policies.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:lucid="lucid" width="1510" height="536.25"><g transform="translate(-10 -80)" lucid:page-tab-id="0_0"><path d="M0 0h1870.87v1322.83H0z" fill="#fff"/><path d="M500 154.93c0-3.32 2.7-6 6-6h268c3.3 0 6 2.68 6 6v184.25c0 3.3-2.7 6-6 6H506c-3.3 0-6-2.7-6-6z" stroke="#5e5e5e" stroke-width="3" fill-opacity="0"/><use xlink:href="#a" transform="matrix(1,0,0,1,505,153.92578125000006) translate(135 18.5644531249 [...]
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.10.0/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.10.0/concepts-messaging.md
index 4666ae9f4c5..55073f9ce9f 100644
--- a/site2/website-next/versioned_docs/version-2.10.0/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.10.0/concepts-messaging.md
@@ -854,6 +854,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message redelivery
Apache Pulsar supports graceful failure handling and ensures critical data is not lost. Software will always have unexpected conditions and at times messages may not be delivered successfully. Therefore, it is important to have a built-in mechanism that handles failure, particularly in asynchronous messaging as highlighted in the following examples.
diff --git a/site2/website-next/versioned_docs/version-2.10.0/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.10.0/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.10.0/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.10.0/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.8.0/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.8.0/concepts-messaging.md
index 794230e0bde..f45a6f2592c 100644
--- a/site2/website-next/versioned_docs/version-2.8.0/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.8.0/concepts-messaging.md
@@ -581,6 +581,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.8.0/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.8.0/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.8.0/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.8.0/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.8.1/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.8.1/concepts-messaging.md
index 4d9ea432b98..f0ab46e74dc 100644
--- a/site2/website-next/versioned_docs/version-2.8.1/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.8.1/concepts-messaging.md
@@ -581,6 +581,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.8.1/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.8.1/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.8.1/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.8.1/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.8.2/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.8.2/concepts-messaging.md
index 296c15dda7e..efba4c77bc5 100644
--- a/site2/website-next/versioned_docs/version-2.8.2/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.8.2/concepts-messaging.md
@@ -581,6 +581,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.8.2/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.8.2/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.8.2/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.8.2/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.8.3/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.8.3/concepts-messaging.md
index 296c15dda7e..efba4c77bc5 100644
--- a/site2/website-next/versioned_docs/version-2.8.3/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.8.3/concepts-messaging.md
@@ -581,6 +581,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.8.3/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.8.3/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.8.3/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.8.3/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.9.0/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.9.0/concepts-messaging.md
index d55de585267..40c7ef7a2f3 100644
--- a/site2/website-next/versioned_docs/version-2.9.0/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.9.0/concepts-messaging.md
@@ -595,6 +595,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.9.0/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.9.0/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.9.0/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.9.0/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.9.1/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.9.1/concepts-messaging.md
index d55de585267..40c7ef7a2f3 100644
--- a/site2/website-next/versioned_docs/version-2.9.1/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.9.1/concepts-messaging.md
@@ -595,6 +595,38 @@ Producer<byte[]> producer = client.newProducer()
```
+
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.9.1/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.9.1/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.9.1/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.9.1/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file
diff --git a/site2/website-next/versioned_docs/version-2.9.2/concepts-messaging.md b/site2/website-next/versioned_docs/version-2.9.2/concepts-messaging.md
index d55de585267..1292ad22b6b 100644
--- a/site2/website-next/versioned_docs/version-2.9.2/concepts-messaging.md
+++ b/site2/website-next/versioned_docs/version-2.9.2/concepts-messaging.md
@@ -595,6 +595,37 @@ Producer<byte[]> producer = client.newProducer()
```
+## System topic
+
+System topic is a predefined topic for internal use within Pulsar. It can be either persistent or non-persistent topic.
+
+System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for healthcheck to internally enable producer/reader to procude/consume messages under the heartbeat namespace, which [...]
+
+There are diverse system topics depending on namespaces. The following table outlines the available system topics for each specific namespace.
+
+| Namespace | TopicName | Domain | Count | Usage |
+|-----------|-----------|--------|-------|-------|
+| pulsar/system | `transaction_coordinator_assign_${id}` | Persistent | Default 16 | Transaction coordinator |
+| pulsar/system | `_transaction_log${tc_id}` | Persistent | Default 16 | Transaction log |
+| pulsar/system | `resource-usage` | Non-persistent | Default 4 | Resource group service |
+| host/port | `heartbeat` | Persistent | 1 | Heartbeat detection |
+| User-defined-ns | [`__change_events`](concepts-multi-tenancy.md#namespace-change-events-and-topic-level-policies) | Persistent | Default 4 | Topic events |
+| User-defined-ns | `__transaction_buffer_snapshot` | Persistent | One per namespace | Transaction buffer snapshots |
+| User-defined-ns | `${topicName}__transaction_pending_ack` | Persistent | One per every topic subscription acknowledged with transactions | Acknowledgements with transactions |
+
+:::note
+
+* You cannot create any system topics.
+* By default, system topics are disabled. To enable system topics, you need to change the following configurations in the `conf/broker.conf` or `conf/standalone.conf` file.
+
+ ```conf
+ systemTopicEnabled=true
+ topicLevelPoliciesEnabled=true
+ ```
+
+:::
+
+
## Message retention and expiry
By default, Pulsar message brokers:
diff --git a/site2/website-next/versioned_docs/version-2.9.2/concepts-multi-tenancy.md b/site2/website-next/versioned_docs/version-2.9.2/concepts-multi-tenancy.md
index be752ccbbf9..730458c9046 100644
--- a/site2/website-next/versioned_docs/version-2.9.2/concepts-multi-tenancy.md
+++ b/site2/website-next/versioned_docs/version-2.9.2/concepts-multi-tenancy.md
@@ -46,14 +46,22 @@ persistent://tenant/app1/topic-3
### Namespace change events and topic-level policies
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store name [...]
-
-- Avoid using ZooKeeper and introduce more loads to ZooKeeper.
+- Avoid using ZooKeeper and introducing more loads to ZooKeeper.
- Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
- Use Pulsar SQL to query the namespace changes and audit the system.
-Each namespace has a system topic `__change_events`. This system topic is used for storing change events for a given namespace. The following figure illustrates how to use namespace change events to implement a topic-level policy.
+Each namespace has a [system topic](concepts-messaging.md#system-topic) named `__change_events`. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
+
+
+
+1. Pulsar Admin clients communicate with the Admin Restful API to update topic-level policies.
+2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding system topic (`__change_events`) of the namespace.
+3. Each broker that owns a namespace bundle(s) subscribes to the system topic (`__change_events`) to receive the change events of the namespace.
+4. Each broker applies the change events to its policy cache.
+5. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+
+:::note
+
+By default, the system topic is disabled. To enable topic-level policy (`topicLevelPoliciesEnabled`=`true`), you need to enable the system topic by setting `systemtopicenabled` to `true` in the `conf/broker.conf` or `conf/standalone.conf` file.
-1. Pulsar Admin clients communicate with the Admin Restful API to update topic level policies.
-2. Any broker that receives the Admin HTTP request publishes a topic policy change event to the corresponding `__change_events` topic of the namespace.
-3. Each broker that owns a namespace bundle(s) subscribes to the `__change_events` topic to receive change events of the namespace. It then applies the change events to the policy cache.
-4. Once the policy cache is updated, the broker sends the response back to the Pulsar Admin clients.
+:::
\ No newline at end of file