Java Magazine, March/April 2017

ORACLE COM JAVAMAGAZINE MARCH APRIL 2017 49 iot When I create an instance of the MessageActionListener class I need to specify the topic to which the message is going to be published the message text and a user context The constructor saves the received values in immutable fields that have the same names as the received arguments The class implements the onSuccess method required by the IMqttActionListener interface Whenever an instance of the MessageActionListener class is used as a callback for an asynchronous action the Java client invokes the onSuccess method when the action has been completed successfully and it passes an asynchronous action token asyncActionToken of type IMqttToken as an argument to specify the action that has been completed The method makes sure that asyncActionToken is not null and checks whether the value returned by asyncActionToken getUserContext matches the user Context saved by the constructor If they match the successful event is related to the event I wanted to monitor for its successful execution and the code displays a message containing the message text that has been published and the name of the destination topic I use an instance of this class as a callback for each message that is published and thereby I can see all the successfully published messages The class also implements the onFailure method which is required by the IMqttActionListener interface and simply calls the printStackTrace method for the received exception Specifying the Quality of Service What does it mean that a message was successfully delivered by the MQTT broker It depends on the quality of service QoS that you select when you work with the MQTT protocol The QoS level is the agreement between the publisher and the receiver of a message about the guarantees for delivering the message Delivering a message involves publishing from the client to the broker and then from the broker to the subscribed client MQTT supports three possible QoS values Level 0 means at most once This level provides the same guarantee as the TCP protocol The message is not acknowledged by the receiver The sender neither stores nor redelivers any messages As you might expect this level has the lowest overhead Level 1 means at least once This level provides a guarantee that the message will be delivered at least once to the receiver The main drawback is that this QoS level might generate duplicates because the message can be delivered more than once The sender stores the message until it receives an acknowledgment In the event the acknowledgment isnt received within a specific time the sender will publish again Level 2 means exactly once This level provides a guarantee that the message is delivered only once to the receiver This QoS level makes sure the message isnt delivered more than once and therefore there is no chance for duplicates However as you might expect it has the highest overhead because it requires two flows between the sender and receiver one to receive the other to send acknowledgment of receipt Only when the entire flow is completed is the message considered to be successfully delivered In this example I will work with QoS level 2 because I dont want the possibility of receiving a command twice Messages are delivered even across network and client restarts However for that to occur each message needs to be stored in a safe location until it has been successfully delivered The Java client works with a pluggable persistence mechanism to store the messages To keep things simple in this example I will use memory based persistence which is not the best What does it mean that a message was successfully delivered by the MQTT broker It depends on the quality of service QoS that you select