The LwM2M agent publishes all inbound messages from LwM2M devices to the MQTT service under the topic lwm2m/data. Our devices use LwM2M “send” to send data to Cumulocity.
Like all topics, the message backlog for this topic is subject to service quotas (25MiB / 36 hours).
Given that all devices connected to a tenant have their messages published to this topic, there is a risk that this backlog could fill up quite quickly if there are many devices and the message consumer is unable to pull the messages from the backlog fast enough or is briefly unavailable (e.g. the microservice hosting the consumer is being restarted).
If a topic backlog is full, the documentation describes the following behaviour:
When the backlog limit is reached, further attempts to publish to the topic will fail until some messages have been consumed.
Can we interpret this to mean that the LwM2M agent will fail to publish to a full backlog (for topic lwm2m/data) and, if so, will it therefore not acknowledge receipt of the LwM2M “send” data from the device? If this is the case, the device will persist the data and attempt to resend it later. However, if the LwM2M agent acknowledges the “send” but fails to publish to the MQTT service, the data will be lost.
Martin,
happy to clarify this quickly. Please note first that the LWM2M MQTT Broker integration currently is a feature we only offer as part of a private preview, and things can be expected to change.
Regarding the quota limit, we’re able to adjust this value if required for a certain customer or use-case. If you should run into problems, please raise a support ticket with us.
Can we interpret this to mean that the LwM2M agent will fail to publish to a full backlog (for topic lwm2m/data) and, if so, will it therefore not acknowledge receipt of the LwM2M “send” data from the device?
Thanks for raising this question. I’ve just checked this in our code base. Indeed, the private preview implementation decouples the reception of LWM2M data from the actual push to the MQTT service; the corresponding internal calls are asynchronous. As a result, the LWM2M devices might be unaware that data forwarding via MQTT hasn’t been happening as expected.
As part of the productification of this feature we are going to make sure that this push to MQTT is done synchronously. If the buffers should be full by any chance, the devices then should see a COAP response indicating a server error, most likely a 5.03.
Kind Regards,
Elias
1 Like
Thanks for the information, Elias. It is helpful to know that we can request a change to the quota limit, but especially good to hear that the LwM2M agent will publish to the MQTT service synchronously with receiving data from the device, so that it can propagate any errors back to the device.