How can a receiving app control that the message is not taken out of the queue, till it sends an acknowledgement of the message? For example, a scenario where the receiving app gets the message and crashes post that, the message from MQ perspective would have been sent but the receiving app would not have yet processed it and in that sense there is a possibility of losing messages. Is there a way that we can control when MQ takes off that message from the queue?
Similar question from sending app perspective, what is the SLA of MQ Light on Bluemix, so if MQLight goes down, should the sending application continue to resend (for how long) the message. How can sending app can be sure of MQLight receiving it?
An app can use the 'Quality of service' property in a subscribe call to control the delivery guarantee for messages it receives. The following provides a good description of the details: https://developer.ibm.com/messaging/mq-light/docs/qos/
In summary, if your app needs to use message acknowledgement then an 'Atleast once' quality of service should be used. Further control is then also possible by using the autoConfirm property if you need the app to control the sending of the ack itself.
Likewise, when sending messages, an application can set the 'Quality of service' property of the send call to 'Atleast once' to receive an explicit accepted/rejected confirmation from the server.
For a situation where the server is unavailable for a period of time, this would mean the client would continue to try to reconnect and send the message until either (1) the server is available again and accepted the message, (2) the server is available again and rejected the message, (3) the client api was changed to the stopped state by the client application or (4) the client application was terminated. In cases 1-3 the client will receive confirmation of the result.
