How to properly manage subscriptions

[pintify]

I've been checking this guide regarding Cloud Connectors implementation but I'm a bit confused about the CloudSubscriptionRecord.

The documentation specifies that the key for the subscriptions map should not be only the topic but also the QoS, however the CloudSubscriptionRecord proposed as example only uses the topic to process hashCode, equals and match. I get how the match method is useful considering only the topic so that it can be filtered in the entrySet. But how can the HashMap tell different CloudSubscriptionRecord by QoS if the equals and hash method only checks topic? Is there something I'm missing?

[pintify]

Moreover, regarding the DataService, should it support multiple qos subscriptions on the same topic? But also an unsubscription? Because the unsuscribe method of the interface does not support that.

[marcellorinaldo]

What we usually do in that case in to call the unsubscribe(String topic) only when we have no more subscribers on that topic, i.e. the map of registered subscribers on that topic is empty. I suppose that this API derives directly from Eclipse Paho MQTT Client.

[pintify]

That's what I was considering, control the subscription from the CloudService, but I'm starting to think that it's really something to do only if needed as you said in the comment below. Thanks for the insight!

[pintify]

Actually, I've investigated a bit more and the MQTT 3.1.1 specification says:

If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscription’s Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted [MQTT-3.8.4-3].

So there is no way to keep multiple QoS on the same topic anyway.

Considering this, I think the options to manage multiple subscriptions on the same topic with different QoS are:

1. Simple first: Ignore it, just use the first QoS received. -> Acceptable for most of cases, I think.
2. Simple last: Ignore it, just resubscribe whenever you receive a request. -> Acceptable for most of cases, I think. It requires less lines to implement than 1 but is a bit heavier because you must send new requests to the server
3. Highest: Keep trace of the current QoS and resubscribe if a higher QoS is received. The subscription QoS states the maximum accepted based on the QoS of the publication so this could make sense -> Doesn't seem so complex
4. Lowest: Keep trace of the current QoS and resubscribe if a lower QoS is received. -> I think the previous one makes more sense. But who knows! Some uses cases are weird as hell
5. Full implementation: If you really need multiple QoS running from the same CloudConnection I can only think of creating additional connections internally somehow. -> Please don't do this!!

All in all, the third option seems good enough. In fact, that means the CloudSubscriptionRecord is perfect the way it is now!

EDITED: Note that even the third (and fourth) option should consider the QoS of all requests during the unsubscribe event of one listener to be consistent. So it's not as simple as it seems.

[mattdibi]

Hello there @pintify 👋 ,
did you already check out this discussion?

For the remaining question I might need the help of @marcellorinaldo ...

[pintify]

Indeed, that's how I found the guide in the first place hehe. But the merge request didn't help as the subscription registering is not implemented yet and this issue is not addressed in that discussion. But I'm ok if you prefer to close this discussion and move it there.

[marcellorinaldo]

I've been checking this guide regarding Cloud Connectors implementation but I'm a bit confused about the CloudSubscriptionRecord.

The documentation specifies that the key for the subscriptions map should not be only the topic but also the QoS, however the CloudSubscriptionRecord proposed as example only uses the topic to process hashCode, equals and match. I get how the match method is useful considering only the topic so that it can be filtered in the entrySet. But how can the HashMap tell different CloudSubscriptionRecord by QoS if the equals and hash method only checks topic? Is there something I'm missing?

Yes, the CloudSubscriptionRecord should implement a check also for the QoS as you pointed out. I voluntarily specified "something similar to CloudSubscriptionRecord" in that guide knowing that it wasn't the proper solution :). Maybe in the future I will change the guide to include a working example

[pintify]

Ok, that's clear now, thanks!

[marcellorinaldo]

@pintify As you see, managing multiple subscribers on the same topic but different QoS is quite tricky. I suggest doing that only if really needed.