ApsaraMQ for RocketMQ:ApsaraMQ for RocketMQ HTTP SDKs (multiple languages recommended)

Support for multiple programming languages

Usage notes

• Over HTTP, consumers can use long or short polling mode to consume messages obtained from ApsaraMQ for RocketMQ brokers.

  • Long polling: The consumer sends a request to the broker to obtain messages in a specific topic. If no message exists in the topic, the broker suspends the request and returns a response until messages are produced in the topic or the specified period for the long polling elapses.

  • Short polling: If no message exists in the topic, the broker immediately returns a response. After the client receives the response, the client repeatedly initiates subscription requests.

  The following items describe the configuration methods:

  • Long polling: When you initiate a subscription request, set the waitSeconds parameter to a value greater than 0. The maximum value is 30 seconds.

  • Short polling: When you initiate a subscription request, set the waitSeconds parameter to 0 or leave the parameter unspecified.

  For more information, see Operation for consuming messages.

  If you use the short polling mode and no message is produced in the topic, a large number of invalid requests may be generated. You are charged API call fees for these requests. To reduce the number of invalid subscription requests and save costs, we recommend that you use the long polling mode and increase the waiting time for long polling. For information about how to calculate API call fees, see API call fees.

  Important

  To ensure service stability and consumption timeliness, the system automatically changes the long polling mode to the short polling mode if the number of consumers connected to an ApsaraMQ for RocketMQ instance over HTTP exceeds 100. To prevent cost increase caused by an excessively large number of invalid requests after the system changes to the short polling mode, make sure to limit the number of consumer connections.

• Support of access from HTTP SDKs is an enhanced feature of ApsaraMQ for RocketMQ. Self-managed Apache RocketMQ clusters do not provide this feature and cannot be accessed using HTTP SDKs.

• Make sure that the resources you want to access are in the same region as the HTTP endpoint you use.

  For example, if your ApsaraMQ for RocketMQ instance is in the China (Hangzhou) region, you can use only the endpoint in the China (Hangzhou) region to access the instance. Take note of the following points:

  • If your client is in the China (Hangzhou) region, use the HTTP internal endpoint of the instance to access resources for optimal user experience.

  • If your client is in a region other than the China (Hangzhou) region, make sure that the client can connect to the Internet and use the HTTP public endpoint of the instance to access resources.

• Messages can be transmitted between TCP and HTTP clients. As XML serialization is used for HTTP, message attributes, bodies, tags, and keys must meet XML rules.

  Note

  For more information about XML rules, see XML syntax. You can also use the third-party tool XML Validator to verify whether your XML syntax complies with the rules.

  If characters that do not comply with XML rules are contained, the following issues may occur:

  • If messages are sent over HTTP, they will fail to be sent.

  • If messages are sent over TCP and consumed over HTTP, they will fail to be consumed.

  You can encode or decode messages you want to send using Base64 to send and receive messages that do not meet XML rules.