Billing

I have purchased a Message Queue for MQTT instance and paid for it. Why are fees still deducted after I send a message?

The fees that you paid for a subscription Message Queue for MQTT instance covers only message transmission and storage of Message Queue for MQTT, but do not cover topic usage fees of Message Queue for Apache RocketMQ or fees for API calls made by Message Queue for Apache RocketMQ over TCP.

Usage

Q1: How do I do if I receive an alert text message that indicates the use of an invalid group ID?

Cause:

To access Message Queue for MQTT, a Message Queue for MQTT client must first apply for a group ID in the console. If a group ID that is not approved is used, the Message Queue for MQTT client may be disconnected and fail to send and receive messages.

Suggestions:

If the alert text message notifies you of an invalid group ID, log on to the Message Queue for MQTT console. In the left-side navigation pane, click Groups to check whether the group ID is created. If it is not created, create a group ID. Make sure that the group ID complies with the naming rules.

Q2: How do I do if I receive an alert text message that indicates the number of stored offline messages exceeds the system limit?

Cause:

Message Queue for MQTT limits the number of offline messages that are stored in each instance. For more information about the limit, see Limits. If the number of offline messages exceeds the limit due to improper subscription settings for your Message Queue for MQTT clients, the system deletes the offline messages from the earliest one until the number falls under the limit.

Suggestions:

  • Based on the instance ID in the alert text message, check whether persistent sessions and QoS1 subscriptions are used for the corresponding Message Queue for MQTT clients.
  • Check whether most of the Message Queue for MQTT clients are offline.
  • Check whether messages are still sent to the offline Message Queue for MQTT clients.
  • If the problem is caused by invalid settings, set cleanSession to true and submit a ticket to delete invalid data.
Note

Subscriptions with persistent sessions are applicable only in the scenario where the client uses the same client ID each time it goes online and the client needs to obtain the messages that it failed to receive during the offline period. Set cleanSession to true if the client ID changes each time the client goes online or the client offline state is irrelevant to services. For more information, see Terms.

Q3: How do I do if a Message Queue for MQTT client is unexpectedly disconnected?

Cause:

  • The Message Queue for MQTT broker checks the permissions of the Message Queue for MQTT client when the Message Queue for MQTT client sends messages for publishing and subscription. The Message Queue for MQTT client is disconnected if it fails to pass the check.
  • The Message Queue for MQTT clients that use the same client ID to access Message Queue for MQTT are forcibly disconnected.

Suggestions:

Make sure that each client ID is globally unique and that different Message Queue for MQTT clients do not use the same client ID to connect to Message Queue for MQTT. In addition, define the reconnection logic.

Q4: How do I do if the messages of a subscribed topic that is no longer needed are still pushed?

Cause:

Subscriptions in the Message Queue Telemetry Transport (MQTT) protocol are persistent. Therefore, if you do not need to subscribe to a topic, call the unsubscribe method to cancel the subscription.

Q5: Why are messages of some topics not received?

Cause:

The number of subscriptions available for each Message Queue for MQTT client is limited. For more information, see Limits. If a Message Queue for MQTT client tries to subscribe to more topics than this limit, messages of the topics that exceed the limit are dropped and cannot be received.