Message Type

• Normal messages

• Scheduled and delayed messages

• ordered messages

• Transactional messages

Normal messages

A normal message is a message that does not have features in a MSMQ. It is different from scheduled /delayed messages, ordered messages, and transactional messages that have features.

Sample code for sending and TCP Java SDK normal messages

• Send normal messages (three methods)

• Send messages (multi-threading)

• Subscribe to messages

Scheduled and delayed messages

• Scheduled message: The producer sends a message to the MSMQ server. However, the producer does not expect the message to be delivered immediately. Instead, the message is delivered to the consumer for consumption at a certain time after the current time point. This message is a scheduled message.

• Delayed message: The producer sends a message to the MSMQ broker. However, the producer does not expect the message to be delivered immediately. Instead, the message is delivered to the consumer for consumption after a certain period of time. The message is a delayed message.

Applicable Scenarios

Scheduled messages and delayed messages are suitable for the following scenarios:

Message production and consumption have time window requirements: for example, in the ant forest scenario, when the relevant low-carbon behavior is triggered, a scheduled message will be sent to the consumer at 7 o'clock the next day to generate green energy, or a delayed message will be sent to generate green energy after 24 hours.

Usage

The use of scheduled messages and delayed messages is slightly different in code writing:

• To send a scheduled message, you must specify a time point after the message sending time as the message delivery time point.

• When you send a delayed message, you need to set a delay time. The message will be delivered after a fixed period of time from the current sending point.

Precautions

• The msg.setStartDeliverTime parameter of the timing and delay message needs to be set to a time (in milliseconds) after the current timestamp. If it is set to a time before the current timestamp, the message will be delivered to the consumer immediately.

• The msg.setStartDeliverTime parameters of scheduled and delayed messages can be set at any time (unit: milliseconds) within three days. If the time exceeds three days, the message fails to be sent.

• The StartDeliverTime is the time when the server starts delivering data to the consumer. If the consumer currently has accumulated messages, scheduled and delayed messages will be ranked after accumulated messages and will not be delivered strictly according to the configured time.

• Because there may be a time difference between the client and the server, there may be a deviation between the actual delivery time of the message and the delivery time set by the client.

• After you set the delivery time of scheduled and delayed messages, the message retention period of three days is still limited.

TCP sample code

For more information about the Java sample code for sending and receiving scheduled and delayed messages, see Send and receive delayed messages.

Ordermessage

Orbined messages (FIFO messages) are messages provided by MSMQ that are published and consumed in strict order. Sequential publishing and sequential consumption means that for a specified topic, the producer publishes messages in a certain order, and the consumer subscribes to messages in a predetermined order, that is, the first published messages are received by the client first.

Partitioned ordered messages are currently supported.

Partitioned ordered messages

For a specified topic, all messages are partitioned based on the sharding key. Messages in the same partition are published and consumed in strict FIFO order. A shard key is a key field that is used in ordered messages to distinguish different partitions. It is completely different from the key used in normal messages.

• Partitionally ordered messages are typically used in scenarios where the performance requirements are high and messages in each partition must be published and consumed in strict FIFO order.

• Example:

  Consider a scenario where a verification code is required for user registration and the user ID is used as the shard key. The messages sent by the same user are published and consumed in FIFO order.

Precautions

When you use ordered messages, take note of the following points:

• Ordered messages do not support broadcasting consumption.

• Each group ID is used for only one type of topics. That is, a single group ID cannot be used to send or subscribe to both ordered messages and unordered messages.

• Ordered messages cannot be sent in asynchronous mode. If ordered messages are sent in asynchronous mode, messages may be disordered.

TCP SDK sample code

For more information about the sample code over TCP, see Send and receive ordered messages.

Transactional messages

• Transactional messages: MSMQ provide a distributed transaction function similar to X/Open XA, which can achieve the final consistency of distributed transactions by MSMQ transaction messages.

• Semi-transactional message: a message that cannot be delivered temporarily. The sender has successfully sent the message to the MSMQ server, but the server does not receive a second acknowledgement from the producer. At this time, the message is marked as "temporarily undeliverable". A message in this state is a semi-transactional message.

• Message query: If the secondary acknowledgment of a transactional message is lost due to a network disconnection or the restart of the producer application, MSMQ the broker scans and finds that a message is a half-transactional message for a long period of time, it needs to ask the message producer about the final status of the message (Commit or Rollback).

Applicable Scenarios

In the transfer process, such as from Alipay to Yu'ebao, the data between the two systems needs to be kept eventual consistency, which can be processed through transaction messages. Before Alipay deduction execution, send a semi-transaction message, after the successful execution of the deduction transaction, update the message status to Commit, balance treasure system to subscribe to the MSMQ deduction message, do the corresponding deposit business processing.

Interaction Process

The following figure shows the interaction process of transactional messages.

To send a transactional message, perform the following steps:

1. The sender sends a half transactional message to the MSMQ server.

2. After the MSMQ server has successfully persisted the message, it returns an Ack to the sender to confirm that the message has been sent. In this case, the message is a half message.

3. The sender starts executing the local transaction logic.

4. The sender submits a second acknowledgement (Commit or Rollback) to the broker based on the execution result of the local transaction. After the broker receives the Commit status, the broker marks the half transactional message as deliverable, and the subscriber eventually receives the message. After the broker receives the Rollback status, the broker deletes the half transactional message, and the subscriber does not receive the message.

To query transactional messages, perform the following steps:

1. In the special case of network disconnection or application restart, the secondary confirmation submitted in step 4 above does not reach the server, and the server will initiate a message return after a fixed period of time.

2. After the sender receives the message, it needs to check the final result of the local transaction execution of the corresponding message.

3. The sender submits a second acknowledgment based on the final status of the local transaction. The server still performs operations on half-transactional messages in Step 4.

Precautions

1. The group ID of a transactional message cannot be shared with the group ID of other types of messages. Unlike other types of messages, transactional messages have a back-up mechanism. When back-up, the MSMQ server queries the client based on the group ID.

2. When you create a producer for transactional messages by AccessPoint.getAccessPoint().createTransactionProducer, you must specify the LocalTransactionChecker implementation class to handle the return of transactional messages in case of exceptions.

3. After a transactional message is sent to complete a local transaction, the following three states can be returned in the execute method:

   • TransactionStatus.CommitTransaction: Commit the transaction and allow the subscriber to consume the message.

   • TransactionStatus.RollbackTransaction: Rollback transaction, message will be discarded and consumption is not allowed.

   • TransactionStatus.Unknow: The status cannot be determined for the time being. After a fixed period of time, the MSMQ server will check the message back to the sender.

4. You can use one of the following methods to set the maximum time for the first message to be returned:

   Message message =new Message();
   // Add the maximum time, in seconds, for the first message to be returned. For example, the following example sets the actual time for the first time to 120 to 125 seconds.
   message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,"120");
   // The preceding method only determines the fastest time for the first message query. The actual message query time fluctuates backward by 0 to 60 seconds. If the transaction is not committed after the first message query, the message query is performed every 60 seconds. 

TCP SDK sample code

The sample code for sending and receiving transactional messages is as follows:

Send and receive transactional messages TCP Java SDK