Description Pierre-Luc Lacroix 2015-04-09 13:50:12 EDT

Using paho version 1.0.2 (built on Wed Feb 18 12:11:31 EST 2015)

Take the following example where the broker rejects the subscription "a".

------------------------
Test 1
------------------------
Asking for a subscription to topic "a":
<code>
_mqttClient.subscribe("a");
</code>

Results in the following exception being thrown:
<code>
MqttException
MqttException (128)
	at org.eclipse.paho.client.mqttv3.MqttClient.subscribe(MqttClient.java:327)
	at org.eclipse.paho.client.mqttv3.MqttClient.subscribe(MqttClient.java:295)
	at com.lacroix.mqttcore.MQTTClient.subscriptionUpdate(MQTTClient.java:262)
</code>

SUBACK contains 0x80 (Failure) which would warrant the exception.



------------------------
Test 2  (ISSUE/BUG #1)
------------------------

Asking for a subscription to topic "b":
<code>
_mqttClient.subscribe("b");
</code>

In this case, paho will request a QoS of 1 by default. The broker can only provide a QoS of 0 but still allows the subscription.

SUBACK packet contains 0x00 (Success BUT with QoS 0).

Issue: The user is not told that QoS 1 was not successfully granted and that only QoS 0 was provided instead.

I personally don't think this is exception worthy, simply a return code would be sufficient.

------------------------
Test 2  (ISSUE/BUG #2)
------------------------

Asking for a subscription to topic "a" and "b" in the same packet (remember "a" should be rejected by the broker and that "b" will be downgrade to QoS 0):

<code>
String[] requestTopics = { "a", "b" };
int[] requestedQos = { 1, 1 };
_mqttClient.subscribe(requestTopics, requestedQos);
</code>

This is by far the worse scenario, method returns successfully, no exceptions.
If the broker rejects only one of two subscription, paho will not report a failure back.

SUBACK: 0x80 0x00

There are actually two problems in this example:
1) The subscription to "a" failed entirely and the user is never made aware of the issue
2) The subscription to "b" was downgraded to QoS 0 and the user is also not made aware of the issue


-------------------------------------

Hope my explanations were clear enough. To solve these problems we would need the subscribe methods to return useful information (assuming blocking calls) and perhaps a callback would be necessary for non-blocking subscribes (if that is even supported).