[ISSUE 11714][DOC][spelling mistakes]fix spelling mistakes for doc (a…

…pache#11715) * [apache#11714][spelling mistakes]fix spelling mistakes for doc * Update site2/docs/reference-configuration.md Co-authored-by: Anonymitaet <[email protected]> * [ISSUE 11714][docs][spelling mistakes]fix spelling mistakes for doc Co-authored-by: 吴贵虎 <[email protected]> Co-authored-by: Anonymitaet <[email protected]>
cckellogg · Aug 23, 2021 · d887640 · d887640
1 parent 0f8aef2
commit d887640
Show file tree

Hide file tree

Showing 366 changed files with 758 additions and 758 deletions.
diff --git a/site2/docs/administration-dashboard.md b/site2/docs/administration-dashboard.md
@@ -51,12 +51,12 @@ If the Pulsar service runs in standalone mode in `localhost`, the `SERVICE_URL`
 be the IP address of the machine.
 
 Similarly, given the Pulsar standalone advertises itself with localhost by default, you need to
-explicitely set the advertise address to the host IP address. For example:
+explicitly set the advertise address to the host IP address. For example:
 
 ```shell
 $ bin/pulsar standalone --advertised-address 1.2.3.4
 ```
 
 ### Known issues
 
-Currently, only Pulsar Token [authentication](security-overview.md#authentication-providers) is supported.
+Currently, only Pulsar Token [authentication](security-overview.md#authentication-providers) is supported.
diff --git a/site2/docs/administration-load-balance.md b/site2/docs/administration-load-balance.md
@@ -115,7 +115,7 @@ loadBalancerNamespaceMaximumBundles=128
 
 ### Shed load automatically
 
-The support for automatic load shedding is avaliable in the load manager of Pulsar. This means that whenever the system recognizes a particular broker is overloaded, the system forces some traffic to be reassigned to less loaded brokers.
+The support for automatic load shedding is available in the load manager of Pulsar. This means that whenever the system recognizes a particular broker is overloaded, the system forces some traffic to be reassigned to less loaded brokers.
 
 When a broker is identified as overloaded, the broker forces to "unload" a subset of the bundles, the ones with higher traffic, that make up for the overload percentage.
 

diff --git a/site2/docs/administration-pulsar-manager.md b/site2/docs/administration-pulsar-manager.md
@@ -126,7 +126,7 @@ docker run -it -p 9527:9527 -p 7750:7750 -e REDIRECT_HOST=http://localhost -e RE
 * `REDIRECT_HOST`: the IP address of the front-end server.
 * `REDIRECT_PORT`: the port of the front-end server.
 * `DRIVER_CLASS_NAME`: the driver class name of the PostgreSQL database.
-* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgresSQL database.
+* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgreSQL database.
 * `USERNAME`: the username of PostgreSQL.
 * `PASSWORD`: the password of PostgreSQL.
 * `LOG_LEVEL`: the level of log.
@@ -141,13 +141,13 @@ docker run -it -p 9527:9527 -p 7750:7750 -e REDIRECT_HOST=http://localhost -e RE
 ```
 
 * `JWT_TOKEN`: the token of superuser configured for the broker. It is generated by the `bin/pulsar tokens create --private-key` command.
-* `PRIVATE_KEY`: private key path mounted in container, genrated by `bin/pulsar tokens create-key-pair` command.
-* `PUBLIC_KEY`: public key path mounted in container, genrated by `bin/pulsar tokens create-key-pair` command.
+* `PRIVATE_KEY`: private key path mounted in container, generated by `bin/pulsar tokens create-key-pair` command.
+* `PUBLIC_KEY`: public key path mounted in container, generated by `bin/pulsar tokens create-key-pair` command.
 * `$PWD/secret`: the folder where the private key and public key generated by the `bin/pulsar tokens create-key-pair` command are placed locally
 * `REDIRECT_HOST`: the IP address of the front-end server.
 * `REDIRECT_PORT`: the port of the front-end server.
 * `DRIVER_CLASS_NAME`: the driver class name of the PostgreSQL database.
-* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgresSQL database.
+* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgreSQL database.
 * `USERNAME`: the username of PostgreSQL.
 * `PASSWORD`: the password of PostgreSQL.
 * `LOG_LEVEL`: the level of log.
@@ -162,12 +162,12 @@ docker run -it -p 9527:9527 -p 7750:7750 -e REDIRECT_HOST=http://localhost -e RE
 ```
 
 * `JWT_TOKEN`: the token of superuser configured for the broker. It is generated by the `bin/pulsar tokens create --secret-key` command.
-* `SECRET_KEY`: secret key path mounted in container, genrated by `bin/pulsar tokens create-secret-key` command.
+* `SECRET_KEY`: secret key path mounted in container, generated by `bin/pulsar tokens create-secret-key` command.
 * `$PWD/secret`: the folder where the secret key generated by the `bin/pulsar tokens create-secret-key` command are placed locally
 * `REDIRECT_HOST`: the IP address of the front-end server.
 * `REDIRECT_PORT`: the port of the front-end server.
 * `DRIVER_CLASS_NAME`: the driver class name of the PostgreSQL database.
-* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgresSQL database.
+* `URL`: the JDBC URL of your PostgreSQL database, such as jdbc:postgresql://127.0.0.1:5432/pulsar_manager. The docker image automatically start a local instance of the PostgreSQL database.
 * `USERNAME`: the username of PostgreSQL.
 * `PASSWORD`: the password of PostgreSQL.
 * `LOG_LEVEL`: the level of log.

diff --git a/site2/docs/client-libraries-java.md b/site2/docs/client-libraries-java.md
@@ -593,7 +593,7 @@ If a broker dispatches only one message at a time, consumer1 receives the follow
 ("key-4", "message-4-1")
 ```
 
-consumer2 receives the follwoing information.
+consumer2 receives the following information.
 
 ```
 ("key-1", "message-1-2")
@@ -626,7 +626,7 @@ Consumer consumer2 = client.newConsumer()
 
 `Key_Shared` subscription is like `Shared` subscription, all consumers can attach to the same subscription. But it is different from `Key_Shared` subscription, messages with the same key are delivered to only one consumer in order. The possible distribution of messages between different consumers (by default we do not know in advance which keys will be assigned to a consumer, but a key will only be assigned to a consumer at the same time).
 
-consumer1 receives the follwoing information.
+consumer1 receives the following information.
 
 ```
 ("key-1", "message-1-1")
@@ -636,7 +636,7 @@ consumer1 receives the follwoing information.
 ("key-3", "message-3-2")
 ```
 
-consumer2 receives the follwoing information.
+consumer2 receives the following information.
 
 ```
 ("key-2", "message-2-1")

diff --git a/site2/docs/client-libraries-websocket.md b/site2/docs/client-libraries-websocket.md
@@ -69,7 +69,7 @@ All exchanges via the WebSocket API use JSON.
 
 ### Authentication
 
-#### Broswer javascript WebSocket client
+#### Browser javascript WebSocket client
 
 Use the query param `token` transport the authentication token.
 

diff --git a/site2/docs/concepts-messaging.md b/site2/docs/concepts-messaging.md
@@ -519,7 +519,7 @@ The diagram below illustrates both concepts:
 
 ![Message retention and expiry](assets/retention-expiry.png)
 
-With message retention, shown at the top, a <span style="color: #89b557;">retention policy</span> applied to all topics in a namespace dicates that some messages are durably stored in Pulsar even though they've already been acknowledged. Acknowledged messages that are not covered by the retention policy are <span style="color: #bb3b3e;">deleted</span>. Without a retention policy, *all* of the <span style="color: #19967d;">acknowledged messages</span> would be deleted.
+With message retention, shown at the top, a <span style="color: #89b557;">retention policy</span> applied to all topics in a namespace dictates that some messages are durably stored in Pulsar even though they've already been acknowledged. Acknowledged messages that are not covered by the retention policy are <span style="color: #bb3b3e;">deleted</span>. Without a retention policy, *all* of the <span style="color: #19967d;">acknowledged messages</span> would be deleted.
 
 With message expiry, shown at the bottom, some messages are <span style="color: #bb3b3e;">deleted</span>, even though they <span style="color: #337db6;">haven't been acknowledged</span>, because they've expired according to the <span style="color: #e39441;">TTL applied to the namespace</span> (for example because a TTL of 5 minutes has been applied and the messages haven't been acknowledged but are 10 minutes old).
 

diff --git a/site2/docs/deploy-bare-metal.md b/site2/docs/deploy-bare-metal.md
@@ -168,7 +168,7 @@ For more details of how to configure tiered storage feature, you can refer to th
 
 ## Deploy a ZooKeeper cluster
 
-> If you already have an exsiting zookeeper cluster and want to use it, you can skip this section.
+> If you already have an existing zookeeper cluster and want to use it, you can skip this section.
 
 [ZooKeeper](https://zookeeper.apache.org) manages a variety of essential coordination-related and configuration-related tasks for Pulsar. To deploy a Pulsar cluster, you need to deploy ZooKeeper first. A 3-node ZooKeeper cluster is the recommended configuration. Pulsar does not make heavy use of ZooKeeper, so the lightweight machines or VMs should suffice for running ZooKeeper.
 
@@ -372,7 +372,7 @@ You can start a broker in the background using the [`pulsar-daemon`](reference-c
 $ bin/pulsar-daemon start broker
 ```
 
-Once you succesfully start up all the brokers that you intend to use, your Pulsar cluster should be ready to go!
+Once you successfully start up all the brokers that you intend to use, your Pulsar cluster should be ready to go!
 
 ## Connect to the running cluster
 

diff --git a/site2/docs/developing-binary-protocol.md b/site2/docs/developing-binary-protocol.md
@@ -412,7 +412,7 @@ messages are coming from the consumer.
 
 ##### Command ConsumerStats
 
-This command is sent by the client to retreive Subscriber and Consumer level 
+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 

diff --git a/site2/docs/functions-develop.md b/site2/docs/functions-develop.md
@@ -1094,7 +1094,7 @@ Currently Pulsar Functions expose the following APIs for mutating and accessing
 
 ```java
     /**
-     * Increment the builtin distributed counter refered by key
+     * Increment the builtin distributed counter referred by key
      * @param key The name of the key
      * @param amount The amount to be incremented
      */

diff --git a/site2/docs/helm-overview.md b/site2/docs/helm-overview.md
@@ -10,7 +10,7 @@ sidebar_label: Overview
 
 The Apache Pulsar Helm chart provides one of the most convenient ways to operate Pulsar on Kubernetes. With all the required components, Helm chart is scalable and thus being suitable for large-scale deployments.
 
-The Apache Pulsar Helm chart contains all compoments to support the features and functions that Pulsar delivers. You can install and configure these components seperately.
+The Apache Pulsar Helm chart contains all components to support the features and functions that Pulsar delivers. You can install and configure these components separately.
 
 - Pulsar core components:
     - ZooKeeper
@@ -89,7 +89,7 @@ To uninstall the Apache Pulsar Helm chart, run the following command:
 helm delete <pulsar-release-name>
 ```
 
-For the purposes of continuity, some Kubernetes objects in these charts cannot be removed by `helm delete` command. It is recommended to *conciously* remove these items, as they affect re-deployment.
+For the purposes of continuity, some Kubernetes objects in these charts cannot be removed by `helm delete` command. It is recommended to *consciously* remove these items, as they affect re-deployment.
 
 * PVCs for stateful data: remove these items.
     - ZooKeeper: This is your metadata.

diff --git a/site2/docs/reference-configuration.md b/site2/docs/reference-configuration.md
@@ -56,7 +56,7 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |compactionRate|The rate at which compaction will read entries, in adds per second.|1000|
 |isThrottleByBytes|Throttle compaction by bytes or by entries.|false|
 |compactionRateByEntries|The rate at which compaction will read entries, in adds per second.|1000|
-|compactionRateByBytes|Set the rate at which compaction will readd entries. The unit is bytes added per second.|1000000|
+|compactionRateByBytes|Set the rate at which compaction reads entries. The unit is bytes added per second.|1000000|
 |journalMaxSizeMB|Max file size of journal file, in megabytes. A new journal file will be created when the old one reaches the file size limitation.|2048|
 |journalMaxBackups|The max number of old journal files to keep. Keeping a number of old journal files would help data recovery in special cases.|5|
 |journalPreAllocSizeMB|How space to pre-allocate at a time in the journal.|16|
@@ -97,7 +97,7 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |diskUsageThreshold|For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if ‘readOnlyModeEnabled=true’ is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).|0.95|
 |diskCheckInterval|Disk check interval in milli seconds, interval to check the ledger dirs usage.|10000|
 |auditorPeriodicCheckInterval|Interval at which the auditor will do a check of all ledgers in the cluster. By default this runs once a week. The interval is set in seconds. To disable the periodic check completely, set this to 0. Note that periodic checking will put extra load on the cluster, so it should not be run more frequently than once a day.|604800|
-|sortedLedgerStorageEnabled|Whether sorted-ledger storage is enabled.|ture|
+|sortedLedgerStorageEnabled|Whether sorted-ledger storage is enabled.|true|
 |auditorPeriodicBookieCheckInterval|The interval between auditor bookie checks. The auditor bookie check, checks ledger metadata to see which bookies should contain entries for each ledger. If a bookie which should contain entries is unavailable, thea the ledger containing that entry is marked for recovery. Setting this to 0 disabled the periodic check. Bookie checks will still run when a bookie fails. The interval is specified in seconds.|86400|
 |numAddWorkerThreads|The number of threads that should handle write requests. if zero, the writes would be handled by netty threads directly.|0|
 |numReadWorkerThreads|The number of threads that should handle read requests. if zero, the reads would be handled by netty threads directly.|8|
@@ -244,7 +244,7 @@ brokerServiceCompactionThresholdInBytes|If the estimated backlog size is greater
 |offloadersDirectory|The directory for all the offloader implementations.|./offloaders|
 |bookkeeperMetadataServiceUri| Metadata service uri that bookkeeper is used for loading corresponding metadata driver and resolving its metadata service location. This value can be fetched using `bookkeeper shell whatisinstanceid` command in BookKeeper cluster. For example: zk+hierarchical://localhost:2181/ledgers. The metadata service uri list can also be semicolon separated values like below: zk+hierarchical://zk1:2181;zk2:2181;zk3:2181/ledgers ||
 |bookkeeperClientAuthenticationPlugin|  Authentication plugin to use when connecting to bookies ||
-|bookkeeperClientAuthenticationParametersName|  BookKeeper auth plugin implementatation specifics parameters name and values  ||
+|bookkeeperClientAuthenticationParametersName|  BookKeeper auth plugin implementation specifics parameters name and values  ||
 |bookkeeperClientAuthenticationParameters|||
 |bookkeeperClientNumWorkerThreads|  Number of BookKeeper client worker threads. Default is Runtime.getRuntime().availableProcessors()  ||
 |bookkeeperClientTimeoutInSeconds|  Timeout for BK add / read operations  |30|

diff --git a/site2/docs/reference-pulsar-admin.md b/site2/docs/reference-pulsar-admin.md
@@ -2423,7 +2423,7 @@ Options
 |----|---|---|
 |`-e`, `--bookkeeper-ensemble`|Number of bookies to use for a topic|0|
 |`-w`, `--bookkeeper-write-quorum`|How many writes to make of each entry|0|
-|`-a`, `--bookkeeper-ack-quorum`|Number of acks (garanteed copies) to wait for each entry|0|
+|`-a`, `--bookkeeper-ack-quorum`|Number of acks (guaranteed copies) to wait for each entry|0|
 |`-r`, `--ml-mark-delete-max-rate`|Throttling rate of mark-delete operation (0 means no throttle)||
 
 ### `remove-persistence`
@@ -2617,7 +2617,7 @@ Options
 
 
 ### `reset-namespace-bundle-quota`
-Reset the specifed namespace bundle's resource quota to a default value.
+Reset the specified namespace bundle's resource quota to a default value.
 
 Usage
 ```bash

diff --git a/site2/docs/reference-terminology.md b/site2/docs/reference-terminology.md
@@ -46,7 +46,7 @@ modes (exclusive, shared, failover and key_shared).
 
 #### Pub-Sub
 
-A messaging pattern in which [producer](#producer) proccesses publish messages on [topics](#topic) that
+A messaging pattern in which [producer](#producer) processes publish messages on [topics](#topic) that
 are then consumed (processed) by [consumer](#consumer) processes.
 
 #### Producer

diff --git a/site2/docs/security-athenz.md b/site2/docs/security-athenz.md
@@ -41,7 +41,7 @@ For more specific steps involving UI, refer to [Example Service Access Control S
 > ### TLS encryption 
 >
 > Note that when you are using Athenz as an authentication provider, you had better use TLS encryption 
-> as it can protect role tokens from being intercepted and reused. (for more details involving TLS encrption see [Architecture - Data Model](https://github.com/AthenZ/athenz/blob/master/docs/data_model.md)).
+> as it can protect role tokens from being intercepted and reused. (for more details involving TLS encryption see [Architecture - Data Model](https://github.com/AthenZ/athenz/blob/master/docs/data_model.md)).
 
 In the `conf/broker.conf` configuration file in your Pulsar installation, you need to provide the class name of the Athenz authentication provider as well as a comma-separated list of provider domain names.
 

diff --git a/site2/docs/security-authorization.md b/site2/docs/security-authorization.md
@@ -37,7 +37,7 @@ Pulsar uses *Proxy roles* to enable the authentication. Proxy roles are specifie
 
 You must authorize both the *proxy role* and the *original principal* to access a resource to ensure that the resource is accessible via the proxy. Administrators can take two approaches to authorize the *proxy role* and the *original principal*.
 
-The more secure approach is to grant access to the proxy roles each time you grant access to a resource. For example, if you have a proxy role named `proxy1`, when the superuser creats a tenant, you should specify `proxy1` as one of the admin roles. When a role is granted permissions to produce or consume from a namespace, if that client wants to produce or consume through a proxy, you should also grant `proxy1` the same permissions.
+The more secure approach is to grant access to the proxy roles each time you grant access to a resource. For example, if you have a proxy role named `proxy1`, when the superuser creates a tenant, you should specify `proxy1` as one of the admin roles. When a role is granted permissions to produce or consume from a namespace, if that client wants to produce or consume through a proxy, you should also grant `proxy1` the same permissions.
 
 Another approach is to make the proxy role a superuser. This allows the proxy to access all resources. The client still needs to authenticate with the proxy, and all requests made through the proxy have their role downgraded to the *original principal* of the authenticated client. However, if the proxy is compromised, a bad actor could get full access to your cluster.
 

diff --git a/site2/docs/security-jwt.md b/site2/docs/security-jwt.md
@@ -257,7 +257,7 @@ brokerClientAuthenticationParameters={"token":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0
 # Or, alternatively, read token from file
 # brokerClientAuthenticationParameters={"file":"///path/to/proxy-token.txt"}
 
-# Whether client authorization credentials are forwared to the broker for re-authorization.
+# Whether client authorization credentials are forwarded to the broker for re-authorization.
 # Authentication must be enabled via authenticationEnabled=true for this to take effect.
 forwardAuthorizationCredentials=true
 ```