Repository: incubator-rocketmq-site
Updated Branches:
  refs/heads/asf-site c6a0f07ed -> 5b69a90ff


http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/_docs/best-practice-namesvr.md
----------------------------------------------------------------------
diff --git a/_docs/best-practice-namesvr.md b/_docs/best-practice-namesvr.md
index 1679850..d6c16d3 100644
--- a/_docs/best-practice-namesvr.md
+++ b/_docs/best-practice-namesvr.md
@@ -5,12 +5,12 @@ modified: 2016-12-24T15:01:43-04:00
 ---
 
 In Apache RocketMQ, name servers are designed to coordinate each component of 
the distributed system
-and fulfill much of this responsibility through managing topic route 
information.
+and the coordination is mainly achieved through managing topic routing 
information.
 
 {% include toc %}
 
-The management, roughly speaking, consists two parts:
-- Brokers periodically renew meta data, including topics they have, which are 
kept in every name servers.
+Management consists of two parts:
+- Brokers periodically renew meta data kept in every name server.
 - Name servers are serving clients, including producers, consumers and command 
line clients with the latest routing information.
 
 Therefore, before launching brokers and clients, we need to tell them how to 
reach name servers by feeding them with a name server address list.
@@ -18,9 +18,9 @@ In Apache RocketMQ, this can be done in four ways.
 
 ## Programmatic Way
 
-For broker, we may specify 
`namesrvAddr=name-server-ip1:port;name-server-ip2:port` in broker configuration 
file.
+For brokers, we can specify 
`namesrvAddr=name-server-ip1:port;name-server-ip2:port` in broker configuration 
file.
 
-For producers and consumers, we may feed name server address list to them as 
follows:
+For producers and consumers, we can feed name server address list to them as 
follows:
 
 ```java
 DefaultMQProducer producer = new 
DefaultMQProducer("please_rename_unique_group_name");
@@ -30,17 +30,17 @@ DefaultMQPushConsumer consumer = new 
DefaultMQPushConsumer("please_rename_unique
 consumer.setNamesrvAddr("name-server1-ip:port;name-server2-ip:port");
 ```
 
-If you use admin command line from shell, you may specify this way:
+If you use admin command line from shell, you can also specify this way:
 
-```java
+```bash
 sh mqadmin command-name -n name-server-ip1:port;name-server-ip2:port -X 
OTHER-OPTION
 ```
 
-a simple example is:
+A simple example is:
 `sh mqadmin -n localhost:9876 clusterList`
 assuming to query cluster info on the name server node.
 
-If integrating admin tool into your own dashboard, you may
+If you have integrated admin tool into your own dashboard, you can:
 
 ```java
 DefaultMQAdminExt defaultMQAdminExt = new 
DefaultMQAdminExt("please_rename_unique_group_name");
@@ -64,12 +64,12 @@ If you do not specify name server address list using 
previously mentioned method
  the following HTTP end point to acquire and update name server address list 
every two minutes with initial delay of
  ten seconds.
 
-On default, the end point is:
+By default, the end point is:
 
 `http://jmenv.tbsite.net:8080/rocketmq/nsaddr`
 
-You may override `jmenv.tbsite.net` by this java option: 
`rocketmq.namesrv.domain`,
-You may also override `nsaddr` part by this java option: 
`rocketmq.namesrv.domain.subgroup`
+You may override `jmenv.tbsite.net` using this Java option: 
`rocketmq.namesrv.domain`,
+You may also override `nsaddr` part using this Java option: 
`rocketmq.namesrv.domain.subgroup`
 
 If you are running Apache RocketMQ in production, this method is recommended 
because it gives you maximum flexibility
  -- you can dynamically add or remove name server nodes without necessity of 
rebooting your brokers and clients 
@@ -78,7 +78,7 @@ If you are running Apache RocketMQ in production, this method 
is recommended bec
      
 ##  Priority
 
-Methods introduced first take precedence over the latter, namely, <br>
+Methods introduced first take precedence over the latter ones: <br>
 `Programmatic Way > Java Options > Environment Variable > HTTP Endpoint`
 
 

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/_docs/best-practice-producer.md
----------------------------------------------------------------------
diff --git a/_docs/best-practice-producer.md b/_docs/best-practice-producer.md
index 7307a74..8f1d14d 100644
--- a/_docs/best-practice-producer.md
+++ b/_docs/best-practice-producer.md
@@ -9,37 +9,37 @@ Some useful tips for users.
 {% include toc %}
 
 ## SendStatus  
-When sending a message, you will get SendResult and it will contain the 
SendStatus. Firstly, we assume that Message's isWaitStoreMsgOK=true(default is 
true). If not, we will always get SEND_OK if no exception is thrown.
-Follow are the descriptions about each status.
+When sending a message, you will get SendResult which contains SendStatus. 
Firstly, we assume that Message's isWaitStoreMsgOK=true(default is true). If 
not, we will always get SEND_OK if no exception is thrown.
+Below is a list of descriptions about each status:
 ### FLUSH_DISK_TIMEOUT
-If the Broker set MessageStoreConfig's FlushDiskType=SYNC_FLUSH(default is 
ASYNC_FLUSH), and the Broker dose not finish flushing disk within 
MessageStoreConfig's syncFlushTimeout(default is 5 secs), you will get such 
status.
+If the Broker set MessageStoreConfig's FlushDiskType=SYNC_FLUSH(default is 
ASYNC_FLUSH), and the Broker doesn't finish flushing the disk within 
MessageStoreConfig's syncFlushTimeout(default is 5 secs), you will get this 
status.
 ### FLUSH_SLAVE_TIMEOUT
-If the Broker's role is SYNC_MASTER(default is ASYNC_MASTER), and the slave 
Broker dose not finish synchronizing with the master within the 
MessageStoreConfig's syncFlushTimeout(default is 5 secs), you will get such 
status.
+If the Broker's role is SYNC_MASTER(default is ASYNC_MASTER), and the slave 
Broker doesn't finish synchronizing with the master within the 
MessageStoreConfig's syncFlushTimeout(default is 5 secs), you will get this 
status.
 ### SLAVE_NOT_AVAILABLE
-If the Broker's role is SYNC_MASTER(default is ASYNC_MASTER), but no slave 
Broker is configured, you will get such status.
+If the Broker's role is SYNC_MASTER(default is ASYNC_MASTER), but no slave 
Broker is configured, you will get this status.
 ### SEND_OK
-You should be aware that SEND_OK does not mean it is reliable. If you cannot 
tolerate message missing, you should also enable SYNC_MASTER or SYNC_FLUSH.
+SEND_OK does not mean it is reliable. To make sure no message would be lost, 
you should also enable SYNC_MASTER or SYNC_FLUSH.
 ### Duplication or Missing
-If you get FLUSH_DISK_TIMEOUT, FLUSH_SLAVE_TIMEOUT and the Broker happens to 
shutdown right the moment, you may get your message missing.
-At this time, you have two choices, one is letting it go, which may get 
message missing; another is resending, which may get message duplication.
-Often we suggest resend and make a way to handle the duplication removal when 
consuming. Unless you feel it does not matter when some messages are missed.
-But be ware that resending has no use when you get SLAVE_NOT_AVAILABLE, you'd 
better keep the scene and send some alerts to the Cluster Manager. 
+If you get FLUSH_DISK_TIMEOUT, FLUSH_SLAVE_TIMEOUT and the Broker happens to 
shutdown right the moment, you can find your message missing.
+At this time, you have two choices, one is to let it go, which may cause this 
message to be lost; another is to resend the message, which may get message 
duplication.
+Often we suggest resend and find a way to handle the duplication removal when 
consuming. Unless you feel it doesn't matter when some messages are lost.
+But keep in mind that resending is useless when you get SLAVE_NOT_AVAILABLE. 
If this happens, you should keep the scene and alert the Cluster Manager.
 ## Timeout 
-The Client send requests to Broker, and wait the responses, but if the max 
wait time is elapsed and no response is return, the Client will throw a 
RemotingTimeoutException.
-The default wait time is 3 seconds.You can also pass timeout argument using 
send(msg, timeout) instead of send(msg).
-Note that we do not suggest the value to be too small, for the Broker need 
some time to flush disk or synchronize with slave. Also the value may have 
little effect if it is too bigger than syncFlushTimeout for Broker may return a 
response with FLUSH_SLAVE_TIMEOUT or FLUSH_SLAVE_TIMEOUT before the timeout.
+The Client sends requests to Broker, and wait for the responses, but if the 
max wait time has elapsed and no response is returned, the Client will throw a 
RemotingTimeoutException.
+The default wait time is 3 seconds. You can also pass timeout argument using 
send(msg, timeout) instead of send(msg).
+Note that we do not suggest the wait time to be too small, as the Broker needs 
some time to flush the disk or synchronize with slaves. Also the value may have 
little effect if it exceeds syncFlushTimeout by a lot as Broker may return a 
response with FLUSH_SLAVE_TIMEOUT or FLUSH_SLAVE_TIMEOUT before the timeout.
 ## Message Size
-We suggest the message should be no more than 512K.
+We suggest the size of message should be no more than 512K.
 ## Async Sending
-Default send(msg) will block until the response is return. So if you care 
about performance, we suggest you use send(msg, callback) which will act in a 
async way. 
+Default send(msg) will block until the response is returned. So if you care 
about performance, we suggest you use send(msg, callback) which will act in the 
async way.
 ## Producer Group
-Normally, the producer group has no effects. But if you are involved in  
transaction, you should pay attention to it. 
-In default, you can only create only one producer with the same producer group 
in the same JVM. Usually, this is enough.
+Normally, the producer group has no effects. But if you are involved in a 
transaction, you should pay attention to it.
+By default, you can only create only one producer with the same producer group 
in the same JVM, which is usually enough.
 ## Thread Safety 
-The producer is thread-safe, you can just use it in your business logic.
+The producer is thread-safe, you can just use it in your business solution.
 ## Performance
-If you want more than one producer in one JVM, maybe for big data processing, 
we suggest you:
-* use async sending with a few producers(3~5 is enough)
+If you want more than one producer in one JVM for big data processing, we 
suggest:
+* use async sending with a few producers (3~5 is enough)
 * setInstanceName for each producer
 
   

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/_pages/community.md
----------------------------------------------------------------------
diff --git a/_pages/community.md b/_pages/community.md
index a5c324b..70b5e5d 100644
--- a/_pages/community.md
+++ b/_pages/community.md
@@ -23,5 +23,5 @@ We have a few mailing lists hosted by Apache, please refer to 
[here](/about/cont
 
 # Ecosystem
 
-TODO
+![](/assets/images/eco.png)
 

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/_pages/customer.md
----------------------------------------------------------------------
diff --git a/_pages/customer.md b/_pages/customer.md
index c67ef9b..988d624 100644
--- a/_pages/customer.md
+++ b/_pages/customer.md
@@ -30,6 +30,11 @@ feature_row2:
     alt: "Yunpan Group"
   - image_path: /assets/images/community/shihai-logo.jpg
     alt: "Shihai Group"
+feature_row3:
+  - image_path: /assets/images/community/tree-logo.png
+    alt: "Tree Finance Group"
+  - image_path: /assets/images/community/yhsoft-logo.png
+    alt: "YH software Group"
 intro:
   - excerpt: "Who uses Apache RocketMQ ? &nbsp;"
 ---
@@ -40,4 +45,6 @@ intro:
 
 {% include feature_row id="feature_row1" %}
 
-{% include feature_row id="feature_row2" %}
\ No newline at end of file
+{% include feature_row id="feature_row2" %}
+
+{% include feature_row id="feature_row3" %}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/_sass/_archive.scss
----------------------------------------------------------------------
diff --git a/_sass/_archive.scss b/_sass/_archive.scss
index c5d0709..e8aede2 100644
--- a/_sass/_archive.scss
+++ b/_sass/_archive.scss
@@ -63,7 +63,7 @@
   border-radius: $border-radius;
   overflow: hidden;
   img {
-    width: 100%;
+    max-width:60%;
   }
 }
 
@@ -158,6 +158,8 @@
 .feature__item {
   margin-bottom: 2em;
   font-size: 1.25rem;
+  height: 80px;
+  line-height: 80px;
 
   @include breakpoint($small) {
     margin-bottom: 0;

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/assets/images/community/tree-logo.png
----------------------------------------------------------------------
diff --git a/assets/images/community/tree-logo.png 
b/assets/images/community/tree-logo.png
new file mode 100644
index 0000000..a168313
Binary files /dev/null and b/assets/images/community/tree-logo.png differ

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/assets/images/community/yhsoft-logo.png
----------------------------------------------------------------------
diff --git a/assets/images/community/yhsoft-logo.png 
b/assets/images/community/yhsoft-logo.png
new file mode 100644
index 0000000..9bfad50
Binary files /dev/null and b/assets/images/community/yhsoft-logo.png differ

http://git-wip-us.apache.org/repos/asf/incubator-rocketmq-site/blob/fbef4631/assets/images/eco.png
----------------------------------------------------------------------
diff --git a/assets/images/eco.png b/assets/images/eco.png
new file mode 100644
index 0000000..64e58ad
Binary files /dev/null and b/assets/images/eco.png differ

Reply via email to