I have configured a queue named solaceQueue and associated a topic SolaceTopic with it in the Solace AEM dashboard. Using the MQTT framework, I am publishing messages to SolaceTopic with QoS levels 1 and 2. The dashboard indicates that messages are queued successfully.
However, when subscribing to SolaceTopic via MQTT with the same QoS levels, I am unable to receive all the messages that were previously queued. Despite the messages being visible in the dashboard’s queued message count, they are not being delivered to the subscriber.
I have ensured the following configurations:
Clean Session is set to false.
A persistent client ID is used.
The MQTT subscription is made with QoS 1 or 2.
Could you please assist in identifying potential misconfigurations or limitations that might be causing this issue? Any guidance on ensuring reliable message delivery in this setup would be greatly appreciated.
Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:
Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.
AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a . If my response doesn’t make sense for your topic, please react to it with a .
Let me analyze the issue with MQTT message consumption in your iOS application.
The documentation indicates that MQTT message consumption with QoS levels works differently than traditional queue-based consumption:
MQTT doesn’t natively support direct queue consumption. Instead, Solace implements queue functionality under the hood for MQTT connections.
For persistent message consumption with MQTT:
Clean Session must be set to false
The same client ID must be used consistently
QoS 1 must be used for subscriptions
Session expiry interval must be configured in connect properties
Looking at your code, a few adjustments are needed for reliable message consumption:
Set a non-zero sessionExpiryInterval in the connect properties
Ensure you’re using a consistent clientID across connections
Use QoS 1 for both publishing and subscribing
Set cleanSession to false (which you already have)
Although I am not a member of the Solace Support Team, I might be able to help with this.
You cannot create your own custom queue and have an MQTT client consume from it directly. Instead, when you use an MQTT subscription with Quality of Service (QoS) 1, the broker automatically attempts to create a dedicated queue for your session.
This special queue has a name that starts with the prefix #mqtt/<client-id>.
However, for the broker to create this queue, your associated Client Profile needs to have the necessary permission. Since a queue with this naming pattern doesn’t appear in your screenshot, I assume your profile is not permitted to create endpoints during the connection.
So, keep your settings as you described, make sure the Client Profile has the “Allow Client to Create Endpoints” flag enabled and try again.
The lifetime of this #mqtt/... queue is directly tied to the MQTT session. This means as long as you connect with the clean session flag set to false, you can safely disconnect your client.
The queue will persist and continue to collect messages from your subscriptions. When you reconnect using the same client ID, you will be re-bound to the existing queue and can then consume all the messages that were queued during your absence.
. If my response doesn’t make sense for your topic, please react to it with a 
.