You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by aa...@apache.org on 2022/09/18 03:23:55 UTC
[rocketmq] branch develop updated: Fixed intermixing of punctuation marks in English documents (#5086)
This is an automated email from the ASF dual-hosted git repository.
aaronai pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/rocketmq.git
The following commit(s) were added to refs/heads/develop by this push:
new 45937936b Fixed intermixing of punctuation marks in English documents (#5086)
45937936b is described below
commit 45937936b88f818f3c27f04d79b59eaca14e2df0
Author: zhaows <41...@users.noreply.github.com>
AuthorDate: Sun Sep 18 11:23:48 2022 +0800
Fixed intermixing of punctuation marks in English documents (#5086)
---
..._Topic_Logic_Queue_\350\256\276\350\256\241.md" | 2 +-
docs/en/Configuration_TLS.md | 8 ++++----
docs/en/Design_Remoting.md | 2 +-
docs/en/Design_Store.md | 2 +-
docs/en/FAQ.md | 2 +-
docs/en/Operations_Trace.md | 6 +++---
docs/en/README.md | 22 +++++++++++-----------
docs/en/Troubleshoopting.md | 4 ++--
docs/en/architecture.md | 18 +++++++++---------
docs/en/best_practice.md | 2 +-
.../client/java/API_Reference_DefaultMQProducer.md | 2 +-
docs/en/dledger/deploy_guide.md | 4 ++--
docs/en/dledger/quick_start.md | 6 +++---
docs/en/operation.md | 18 +++++++++---------
14 files changed, 49 insertions(+), 49 deletions(-)
diff --git "a/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md" "b/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
index 67cb1d587..784a83f92 100644
--- "a/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
+++ "b/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
@@ -2,7 +2,7 @@
| 时间 | 主要内容 | 作者 |
| --- | --- | --- |
| 2021-11-01 | 初稿，包括背景、目标、SOT定义与持久化、SOT生命周期、SOT的使用、API逻辑修改、问题与风险 | dongeforever |
-| 2021-11-15 | 修改 LogicQueue 的定义，不要引入新字段，完全复用旧的MessageQueue; RemappingStaticTopic时，不要迁移『位点』『幂等数据』等，而是采用Double-Check-Read 的机制| dongforever |
+| 2021-11-15 | 修改 LogicQueue 的定义，不要引入新字段，完全复用旧的MessageQueue；RemappingStaticTopic时，不要迁移『位点』『幂等数据』等，而是采用Double-Check-Read 的机制| dongforever |
| 2021-12-01 | 更新问题与风险，增加关于一致性、OutOfRange、拉取中断的详细说明| dongforever |
| 2021-12-03 | 增加代码走读的说明| dongforever |
| 2021-12-10 | 引入Scope概念，保留『多集群动态零耦合』的集群设计模型 | dongforever |
diff --git a/docs/en/Configuration_TLS.md b/docs/en/Configuration_TLS.md
index 67b5b9e1b..445d186d2 100644
--- a/docs/en/Configuration_TLS.md
+++ b/docs/en/Configuration_TLS.md
@@ -34,7 +34,7 @@ openssl pkcs8 -topk8 -v1 PBE-SHA1-RC4-128 -in client_rsa.key -out client.key
```
## 2 Create tls.properties
-Create tls.properties，correctly configure the path and password of the generated certificates.
+Create tls.properties, correctly configure the path and password of the generated certificates.
```properties
# The flag to determine whether use test mode when initialize TLS context. default is true
@@ -76,13 +76,13 @@ Edit the configuration file under the rocketmq/bin path to make tls.properties c
The value of "tls.config.file" needs to be replaced by the file path created in step 2.
### 3.1 Edit runserver.sh
-Add following content in JAVA_OPT：
+Add following content in JAVA_OPT:
```shell
JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties"
```
### 3.2 Edit runbroker.sh
-Add following content in JAVA_OPT：
+Add following content in JAVA_OPT:
```shell
JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties -Dtls.enable=true"
@@ -102,7 +102,7 @@ tls.client.certPath=/opt/certFiles/client.pem
tls.client.trustCertPath=/opt/certFiles/ca.pem
```
-Add following parameters in JVM. The value of "tls.config.file" needs to be replaced by the file path we created：
+Add following parameters in JVM. The value of "tls.config.file" needs to be replaced by the file path we created:
```properties
-Dtls.client.authServer=true -Dtls.enable=true -Dtls.test.mode.enable=false -Dtls.config.file=/opt/certs/tlsclient.properties
```
diff --git a/docs/en/Design_Remoting.md b/docs/en/Design_Remoting.md
index b7b8c86cb..46e001a1d 100644
--- a/docs/en/Design_Remoting.md
+++ b/docs/en/Design_Remoting.md
@@ -28,7 +28,7 @@ From the above figure, the transport content can be divided into four parts:
(1) Message length: total length, four bytes of storage, occupying an int type;
-(2) Serialization type header length: occupying an int type. The first byte represents the serialization type, and the last three bytes represent the header length；
+(2) Serialization type header length: occupying an int type. The first byte represents the serialization type, and the last three bytes represent the header length;
(3) Header data: serialized header data;
diff --git a/docs/en/Design_Store.md b/docs/en/Design_Store.md
index cbc661305..747c98e6f 100644
--- a/docs/en/Design_Store.md
+++ b/docs/en/Design_Store.md
@@ -14,7 +14,7 @@ Message storage is the most complicated and important part of RocketMQ. This sec
The message storage architecture diagram consists of 3 files related to message storage: `CommitLog` file, `ConsumeQueue` file, and `IndexFile`.
-* `CommitLog`：The `CommitLog` file stores message body and metadata sent by producer, and the message content is not fixed length. The default size of one `CommitLog` file is 1G, the length of the file name is 20 digits, the left side is zero padded, and the remaining is the starting offset. For example, `00000000000000000000` represents the first file, the starting offset is 0, and the file size is 1G=1073741824, when the first `CommitLog` file is full, the second `CommitLog` file is `0 [...]
+* `CommitLog`: The `CommitLog` file stores message body and metadata sent by producer, and the message content is not fixed length. The default size of one `CommitLog` file is 1G, the length of the file name is 20 digits, the left side is zero padded, and the remaining is the starting offset. For example, `00000000000000000000` represents the first file, the starting offset is 0, and the file size is 1G=1073741824, when the first `CommitLog` file is full, the second `CommitLog` file is ` [...]
* `ConsumeQueue`: The `ConsumeQueue` is used to improve the performance of message consumption. Since RocketMQ uses topic-based subscription mode, message consumption is specific to the topic. Traversing the commitlog file to retrieve messages of one topic is very inefficient. The consumer can find the messages to be consumed according to the `ConsumeQueue`. The `ConsumeQueue`(logic consume queue) as an index of the consuming message stores the starting physical offset `offset` in `Commi [...]
* `IndexFile`: The `IndexFile` provides a way to query messages by key or time interval. The path of the `IndexFile` is `$HOME/store/index/${fileName}`, the file name `fileName` is named after the timestamp when it was created. One IndexFile's size is about 400M, and it can store 2000W indexes. The underlying storage of `IndexFile` is designed to implement the `HashMap` structure in the file system, so RocketMQ's index file is a hash index.
diff --git a/docs/en/FAQ.md b/docs/en/FAQ.md
index 97b9a0e05..dac53ecbf 100644
--- a/docs/en/FAQ.md
+++ b/docs/en/FAQ.md
@@ -70,7 +70,7 @@ consumer.setConsumeThreadMax(20);
### 1. If you start a producer or consumer failed and the error message is producer group or consumer repeat.
-Reason：Using the same Producer /Consumer Group to launch multiple instances of Producer/Consumer in the same JVM may cause the client fail to start.
+Reason: Using the same Producer /Consumer Group to launch multiple instances of Producer/Consumer in the same JVM may cause the client fail to start.
Solution: Make sure that a JVM corresponding to one Producer /Consumer Group starts only with one Producer/Consumer instance.
diff --git a/docs/en/Operations_Trace.md b/docs/en/Operations_Trace.md
index 5cc003ce4..74c2cde1a 100644
--- a/docs/en/Operations_Trace.md
+++ b/docs/en/Operations_Trace.md
@@ -46,10 +46,10 @@ For scenarios with large amount of trace message data , one of the Broker nodes
RocketMQ's message trace feature supports two ways to store trace data:
### 3.1 System-level TraceTopic
-By default, message track data is stored in the system-level TraceTopic(names：**RMQ_SYS_TRACE_TOPIC**)。This Topic is automatically created when the Broker node is started(As described above, the switch variable **traceTopicEnable** needs to be set to **true** in the Broker configuration file）。
+By default, message track data is stored in the system-level TraceTopic(names: **RMQ_SYS_TRACE_TOPIC**).This Topic is automatically created when the Broker node is started(As described above, the switch variable **traceTopicEnable** needs to be set to **true** in the Broker configuration file）.
### 3.2 Custom TraceTopic
-If the user is not prepared to store the message track data in the system-level default TraceTopic, you can also define and create a user-level Topic to save the track (that is, to create a regular Topic to save the message track data)。The following section introduces how the Client interface supports the user-defined TraceTopic.
+If the user is not prepared to store the message track data in the system-level default TraceTopic, you can also define and create a user-level Topic to save the track (that is, to create a regular Topic to save the message track data).The following section introduces how the Client interface supports the user-defined TraceTopic.
## 4 Client Practices that Support Message Trace
In order to reduce as much as possible the transformation work of RocketMQ message trace feature used in the user service system, the author added a switch parameter (**enableMsgTrace**) to the original interface in the design to realize whether the message trace is opened or not.
@@ -95,7 +95,7 @@ In order to reduce as much as possible the transformation work of RocketMQ messa
The initialization of `DefaultMQProducer` and `DefaultMQPushConsumer` instances can be changed to support the custom storage message trace Topic as follows when sending and subscribing messages above.
```
- ##Where Topic_test11111 needs to be pre-created by the user to save the message trace；
+ ##Where Topic_test11111 needs to be pre-created by the user to save the message trace;
DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName",true,"Topic_test11111");
......
diff --git a/docs/en/README.md b/docs/en/README.md
index e1e569e5a..2a096c334 100644
--- a/docs/en/README.md
+++ b/docs/en/README.md
@@ -5,39 +5,39 @@
### 1. Concepts & Features
-- [Concept](Concept.md)：introduce basic concepts in RocketMQ.
+- [Concept](Concept.md): introduce basic concepts in RocketMQ.
-- [Feature](Feature.md)：introduce functional features of RocketMQ's implementations.
+- [Feature](Feature.md): introduce functional features of RocketMQ's implementations.
### 2. Architecture Design
-- [Architecture](architecture.md)：introduce RocketMQ's deployment and technical architecture.
+- [Architecture](architecture.md): introduce RocketMQ's deployment and technical architecture.
-- [Design](design.md)：introduce design concept of RocketMQ's key mechanisms, including message storage, communication mechanisms, message filter, loadbalance, transaction message, etc.
+- [Design](design.md): introduce design concept of RocketMQ's key mechanisms, including message storage, communication mechanisms, message filter, loadbalance, transaction message, etc.
### 3. Example
-- [Example](RocketMQ_Example.md) ：introduce RocketMQ's common usage, including basic example, sequence message example, delay message example, batch message example, filter message example, transaction message example, etc.
+- [Example](RocketMQ_Example.md): introduce RocketMQ's common usage, including basic example, sequence message example, delay message example, batch message example, filter message example, transaction message example, etc.
### 4. Best Practice
-- [Best Practice](best_practice.md)：introduce RocketMQ's best practice, including producer, consumer, broker, NameServer, configuration of client, and the best parameter configuration of JVM, linux.
+- [Best Practice](best_practice.md): introduce RocketMQ's best practice, including producer, consumer, broker, NameServer, configuration of client, and the best parameter configuration of JVM, linux.
-- [Message Trace](msg_trace/user_guide.md)：introduce how to use RocketMQ's message tracing feature.
+- [Message Trace](msg_trace/user_guide.md): introduce how to use RocketMQ's message tracing feature.
-- [Auth Management](acl/Operations_ACL.md)：introduce how to deployment quickly and how to use RocketMQ cluster enabling auth management feature.
+- [Auth Management](acl/Operations_ACL.md): introduce how to deployment quickly and how to use RocketMQ cluster enabling auth management feature.
-- [Quick Start](dledger/quick_start.md)：introduce how to deploy Dledger quickly.
+- [Quick Start](dledger/quick_start.md): introduce how to deploy Dledger quickly.
-- [Cluster Deployment](dledger/deploy_guide.md)：introduce how to deploy Dledger in cluster.
+- [Cluster Deployment](dledger/deploy_guide.md): introduce how to deploy Dledger in cluster.
- [Proxy Deployment](proxy/deploy_guide.md)
Introduce how to deploy proxy (both `Local` mode and `Cluster` mode).
### 5. Operation and maintenance management
-- [Operation](operation.md)：introduce RocketMQ's deployment modes that including single-master mode, multi-master mode, multi-master multi-slave mode and so on, as well as the usage of operation tool mqadmin.
+- [Operation](operation.md): introduce RocketMQ's deployment modes that including single-master mode, multi-master mode, multi-master multi-slave mode and so on, as well as the usage of operation tool mqadmin.
### 6. API Reference（TODO）
diff --git a/docs/en/Troubleshoopting.md b/docs/en/Troubleshoopting.md
index 085b8288a..ee4adab8c 100644
--- a/docs/en/Troubleshoopting.md
+++ b/docs/en/Troubleshoopting.md
@@ -2,7 +2,7 @@
## 1 RocketMQ's mqadmin command error.
-> Problem: Sometimes after deploying the RocketMQ cluster, when you try to execute some commands of "mqadmin", the following exception will appear：
+> Problem: Sometimes after deploying the RocketMQ cluster, when you try to execute some commands of "mqadmin", the following exception will appear:
>
> ```java
> org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <null> failed
@@ -72,5 +72,5 @@ After sending message with RocketMQ, you will usually see the following log:
SendResult [sendStatus=SEND_OK, msgId=0A42333A0DC818B4AAC246C290FD0000, offsetMsgId=0A42333A00002A9F000000000134F1F5, messageQueue=MessageQueue [topic=topicTest1, BrokerName=mac.local, queueId=3], queueOffset=4]
```
-- msgId，for the client, the msgId is generated by the producer instance. Specifically, the method `MessageClientIDSetter.createUniqIDBuffer()` is called to generate a unique Id.
+- msgId, for the client, the msgId is generated by the producer instance. Specifically, the method `MessageClientIDSetter.createUniqIDBuffer()` is called to generate a unique Id.
- offsetMsgId, offsetMsgId is generated by the Broker server when writing a message ( string consists of "IP address + port" and "CommitLog's physical offset address"), and offsetMsgId is the messageId used to query in the RocketMQ console.
diff --git a/docs/en/architecture.md b/docs/en/architecture.md
index 18e1cc002..863a62200 100644
--- a/docs/en/architecture.md
+++ b/docs/en/architecture.md
@@ -6,18 +6,18 @@
The RocketMQ architecture is divided into four parts, as shown in the figure above:
-- Producer：The role of message publishing supports distributed cluster mode deployment. Producer selects the corresponding Broker cluster queue for message delivery through MQ's load balancing module. The delivery process supports fast failure and low latency.
+- Producer: The role of message publishing supports distributed cluster mode deployment. Producer selects the corresponding Broker cluster queue for message delivery through MQ's load balancing module. The delivery process supports fast failure and low latency.
-- Consumer：The role of message consumption supports distributed cluster deployment. Support push, pull two modes to consume messages. It also supports cluster mode and broadcast mode consumption, and it provides a real-time message subscription mechanism to meet the needs of most users.
+- Consumer: The role of message consumption supports distributed cluster deployment. Support push, pull two modes to consume messages. It also supports cluster mode and broadcast mode consumption, and it provides a real-time message subscription mechanism to meet the needs of most users.
-- NameServer：NameServer is a very simple Topic routing registry with a role similar to ZooKeeper in Dubbo, which supports dynamic registration and discovery of Broker. It mainly includes two functions: Broker management, NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information. Then provide a heartbeat detection mechanism to check whether the broker is still alive; routing information management, each NameServer will [...]
+- NameServer: NameServer is a very simple Topic routing registry with a role similar to ZooKeeper in Dubbo, which supports dynamic registration and discovery of Broker. It mainly includes two functions: Broker management, NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information. Then provide a heartbeat detection mechanism to check whether the broker is still alive; routing information management, each NameServer will [...]
-- BrokerServer：Broker is responsible for the storage, delivery and query of messages and high availability guarantees. In order to achieve these functions, Broker includes the following important sub-modules.
-1. Remoting Module：The entire broker entity handles requests from the clients side.
-2. Client Manager：Topic subscription information for managing the client (Producer/Consumer) and maintaining the Consumer
-3. Store Service：Provides a convenient and simple API interface for handling message storage to physical hard disks and query functions.
-4. HA Service：Highly available service that provides data synchronization between Master Broker and Slave Broker.
-5. Index Service：The message delivered to the Broker is indexed according to a specific Message key to provide a quick query of the message.
+- BrokerServer: Broker is responsible for the storage, delivery and query of messages and high availability guarantees. In order to achieve these functions, Broker includes the following important sub-modules.
+1. Remoting Module: The entire broker entity handles requests from the clients side.
+2. Client Manager: Topic subscription information for managing the client (Producer/Consumer) and maintaining the Consumer
+3. Store Service: Provides a convenient and simple API interface for handling message storage to physical hard disks and query functions.
+4. HA Service: Highly available service that provides data synchronization between Master Broker and Slave Broker.
+5. Index Service: The message delivered to the Broker is indexed according to a specific Message key to provide a quick query of the message.
diff --git a/docs/en/best_practice.md b/docs/en/best_practice.md
index 5d70aeed3..da279e297 100755
--- a/docs/en/best_practice.md
+++ b/docs/en/best_practice.md
@@ -72,7 +72,7 @@ Thirdly, the producer is a virtual machine with low reliability, which is not su
In conclusion, it is recommended that the retry process must be controlled by the application.
### 1.3 Send message by oneway
-Typically, this is the process by which messages are sent：
+Typically, this is the process by which messages are sent:
- Client send request to server
- Server process request
diff --git a/docs/en/client/java/API_Reference_DefaultMQProducer.md b/docs/en/client/java/API_Reference_DefaultMQProducer.md
index 0feaff24c..edc141df8 100644
--- a/docs/en/client/java/API_Reference_DefaultMQProducer.md
+++ b/docs/en/client/java/API_Reference_DefaultMQProducer.md
@@ -6,7 +6,7 @@
extends ClientConfig
implements MQProducer`
->`DefaultMQProducer` is the entry point for an application to post messages, out of the box，ca quickly create a producer with a no-argument construction. it is mainly responsible for message sending, support synchronous、asynchronous、one-way send. All of these send methods support batch send. The parameters of the sender can be adjusted through the getter/setter methods , provided by this class. `DefaultMQProducer` has multi send method and each method is slightly different. Make sure [...]
+>`DefaultMQProducer` is the entry point for an application to post messages, out of the box, ca quickly create a producer with a no-argument construction. it is mainly responsible for message sending, support synchronous、asynchronous、one-way send. All of these send methods support batch send. The parameters of the sender can be adjusted through the getter/setter methods , provided by this class. `DefaultMQProducer` has multi send method and each method is slightly different. Make sure [...]
``` java
public class Producer {
diff --git a/docs/en/dledger/deploy_guide.md b/docs/en/dledger/deploy_guide.md
index 55509498d..06cf333a6 100644
--- a/docs/en/dledger/deploy_guide.md
+++ b/docs/en/dledger/deploy_guide.md
@@ -1,7 +1,7 @@
# Dledger cluster deployment
---
## preface
-This document introduces how to deploy auto failover RocketMQ-on-DLedger Group。
+This document introduces how to deploy auto failover RocketMQ-on-DLedger Group.
RocketMQ-on-DLedger Group is a broker group with **same name**, needs at least 3 nodes, elect a Leader by Raft algorithm automatically, the others as Follower, replicating data between Leader and Follower for system high available.
RocketMQ-on-DLedger Group can failover automatically, and maintains consistent.
@@ -12,7 +12,7 @@ RocketMQ-on-DLedger Group can scale up horizontal, that is, can deploy any Rocke
#### 1.1 Write the configuration
each RocketMQ-on-DLedger Group needs at least 3 machines.(assuming 3 in this document)
write 3 configuration files, advising refer to the directory of conf/dledger 's example configuration file.
-key configuration items：
+key configuration items:
| name | meaning | example |
| --- | --- | --- |
diff --git a/docs/en/dledger/quick_start.md b/docs/en/dledger/quick_start.md
index 83fa76236..dfc7894af 100644
--- a/docs/en/dledger/quick_start.md
+++ b/docs/en/dledger/quick_start.md
@@ -3,7 +3,7 @@
### preface
This document is mainly introduced for how to build and deploy auto failover RocketMQ cluster based on DLedger.
-For detailed new cluster deployment and old cluster upgrade document, please refer to [Deployment Guide](deploy_guide.md)。
+For detailed new cluster deployment and old cluster upgrade document, please refer to [Deployment Guide](deploy_guide.md).
### 1. Build from source code
Build phase contains two parts, first, build DLedger, then build RocketMQ.
@@ -45,7 +45,7 @@ If everything goes well, the following content will appear:
-（BID is 0 indicate Master，the others are Follower）
+（BID is 0 indicate Master, the others are Follower）
After startup successful, producer can produce message, and then test failover scenario.
@@ -55,7 +55,7 @@ Stop cluster fastly, execute the following command:
$ sh bin/dledger/fast-try.sh stop
```
-Quick deployment, default configuration is in directory conf/dledger，default storage path is /tmp/rmqstore.
+Quick deployment, default configuration is in directory conf/dledger, default storage path is /tmp/rmqstore.
### 3. Failover
diff --git a/docs/en/operation.md b/docs/en/operation.md
index 9dff41ab7..799862376 100644
--- a/docs/en/operation.md
+++ b/docs/en/operation.md
@@ -34,9 +34,9 @@ The broker[broker-a, 192.169.1.2:10911] boot success...
Cluster contains Master node only, no Slave node, eg: 2 Master nodes, 3 Master nodes, advantages and disadvantages of this mode are shown below:
-- advantages：simple configuration, single Master node broke down or restart do not impact application. Under RAID10 disk config, even if machine broken down and cannot recover, message do not get lost because of RAID10's high reliable(async flush to disk lost little message, sync to disk do not lost message), this mode get highest performance.
+- advantages: simple configuration, single Master node broke down or restart do not impact application. Under RAID10 disk config, even if machine broken down and cannot recover, message do not get lost because of RAID10's high reliable(async flush to disk lost little message, sync to disk do not lost message), this mode get highest performance.
-- disadvantages：during the machine's down time, messages have not be consumed on this machine can not be subscribed before recovery. That will impacts message's instantaneity.
+- disadvantages: during the machine's down time, messages have not be consumed on this machine can not be subscribed before recovery. That will impacts message's instantaneity.
##### 1）Start NameServer
@@ -54,10 +54,10 @@ The Name Server boot success...
##### 2）start Broker cluster
```bash
-### start the first Master on machine A, eg:NameServer's IP is ：192.168.1.1
+### start the first Master on machine A, eg:NameServer's IP is 192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
-### start the second Master on machine B, eg:NameServer's IP is ：192.168.1.1
+### start the second Master on machine B, eg:NameServer's IP is 192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
...
@@ -139,9 +139,9 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
### 2 mqadmin management tool
-> Attentions：
+> Attentions:
>
-> 1. execute command：`./mqadmin {command} {args}`
+> 1. execute command: `./mqadmin {command} {args}`
> 2. almost all commands need -n indicates NameSerer address, format is ip:port
> 3. almost all commands can get help info by -h
> 4. if command contains both Broker address(-b) and cluster name(-c), it's prior to use broker address. If command do not contains broker address, it will executed on all hosts in this cluster. Support only one broker host. -b format is ip:port, default port is 10911
@@ -414,7 +414,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
<td rowspan=8 height=391 class=xl67 width=177 style='border-bottom:1.0pt;
height:292.0pt;border-top:none;width:133pt'>clusterRT</td>
<td rowspan=8 class=xl70 width=175 style='border-bottom:1.0pt;
- border-top:none;width:131pt'>send message to detect each cluster's Broker RT. Message will be sent to ${BrokerName} Topic。</td>
+ border-top:none;width:131pt'>send message to detect each cluster's Broker RT. Message will be sent to ${BrokerName} Topic.</td>
<td class=xl65 width=177 style='width:133pt'>-a</td>
<td class=xl66 width=185 style='width:139pt'>amount, count of detection, RT = sum time /
amount</td>
@@ -1332,7 +1332,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
#### 3.1 RocketMQ's mqadmin command error
-> question description：execute mqadmin occur below exception after deploy RocketMQ cluster.
+> question description: execute mqadmin occur below exception after deploy RocketMQ cluster.
>
> ```java
> org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <null> failed
@@ -1345,7 +1345,7 @@ Solution: execute command `export NAMESRV_ADDR=ip:9876` (ip is NameServer's ip a
> question description: one producer produce message, consumer A can consume, consume B cannot consume, RocketMQ console print:
>
> ```java
-> Not found the consumer group consume stats, because return offset table is empty, maybe the consumer not consume any message。
+> Not found the consumer group consume stats, because return offset table is empty, maybe the consumer not consume any message.
> ```
Solution: make sure that producer and consumer has the same version of rocketmq-client.