wlliqipeng commented on a change in pull request #794: [RIP-9] Add the
introduction of the Operations_Producer in RocketMQ
URL: https://github.com/apache/rocketmq/pull/794#discussion_r258343666
##########
File path: docs/en/Operations_Producer.md
##########
@@ -0,0 +1,44 @@
+### Producer
+----
+##### 1 Message Sending Tips
+###### 1.1 The Use of Tags
+One instance should use one topic as much as possible and the subtype of
messages can be marked by tags. Tag provides extra flexibility to users. In the
consume subscribing process, the messages filtering can only be handled by
using tags when the tags are specified in the message sending process:
`message.setTags("TagA")`
+###### 1.2 The Use of Keys
+A business key can be set in one message and it will be easier to look up the
message on a broker server to diagnose issues during development. Each message
will be created index(hash index) by server, instance can query the content of
this message by topic and key and who consumes the message.Because of the hash
index, make sure that the key should be unique in order to avoid potential hash
index conflict.
+``` java
+// Order Id
+String orderId = "20034568923546";
+message.setKeys(orderId);
+```
+###### 1.3 The Log Print
+When sending a message,no matter success or fail, a message log must be
printed which contains SendResult and Key. It is assumed that we will always
get SEND_OK if no exception is thrown. Below is a list of descriptions about
each status:
+* SEND_OK
+
+SEND_OK means sending message successfully. 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.
+* FLUSH_DISK_TIMEOUT
+
+FLUSH_DISK_TIMEOUT means sending message successfully but the Broker flushing
the disk with timeout. In this kind of condition, the Broker has saved this
message, this message will be lost only if the Broker was down. The
FlushDiskType and SyncFlushTimeout could be specified in MessageStoreConfig. 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
+
+FLUSH_SLAVE_TIMEOUT means sending messages successfully but the slave Broker
does not finish synchronizing with the master. In this kind of condition, the
Broker has saved this message, this message will be lost only if the Broker was
down. 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
+
+SLAVE_NOT_AVAILABLE means sending messages successfully but no slave Broker
configured. In this kind of condition, the Broker has saved this message, this
message will be lost only if the master Broker was down. If the Broker’s role
is SYNC_MASTER(default is ASYNC_MASTER), but no slave Broker is configured, you
will get this status.
Review comment:
‘In this kind of condition, the Broker has saved this message, this message
will be lost only if the master Broker was down.’ the sentence is recommended
to delete
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
