Thanks a lot @SgtSilvio, that clarifies an important issue (sequential delivery per topic).
We are using QoS 1.
And we use have thousands of completely independently operating devices sending signals to a handful of topics like:
where ‘+’ will be used for the publishing devices ID (e.g. ‘1234’).
Our goal is to enable quick acknowledgement of these messages which are being put to a separate service bus by the callback.
Messages from the service bus are later consumed and processed into a key-value store by another app.
If we want a correct ordering of messages, we only need that within the same deviceId+topic combo to avoid that obsolete information from old messages overwrites information of newer messages for a particular device and signal.
If we get your information right it means that for a particular subscription/topic the server will hold back the next message until the client has acknowledged the current message.
Furthermore each client instance uses a thread pool and each subscription uses exactly one dedicated thread of this pool to process the messages of that same subscription (using the callback function provided)
If true, this raises other questions:
When does the client acknowledge the message? Right after queueing the message to the callback or just after the callback execution of the previous message has finished? We assume the latter (i.e. acknowledgment will wait until just after the callback has finished so there is NO client-side queue of already acknowledged messages waiting for processing).
If we have several shared subscriptions (client1, client2, client3) for a wildchart topic ("$share/myGroup/myTopic/+/signal"). How will the server handle this? If client1 is currently working on a message A for “myTopic/AAA/signal” and a message B for “myTopic/BBB/signal” (same shared subscription!) is waiting for delivery? When will the server decide (randomly) where to send message B? Will message B be blocked until message A has been achnowledged, even if the topic is different …/AAA/… versus …/BBB/… ?
That’s unclear because the the callback and initial subscripotion is the same but the topic is actually different.
So is it all actually about the subscription (myTopic/+/signal) or the topic (myTopic/AAA/signal)?
To enable the most efficient and still consistent processing of the signals we would need to know how to subscribe them in the best way.