conditionally acknowledge QoS 1+ messages from handler

[aquark]

It doesn't look like this library provides any way for a handler to signal that it was unable to handle the message (so it should not be PUBACK'ed). How can a handler report that it was unable to process or persist the message and so it needs to be redelivered?

[graebm]

Not sure exactly what you mean by "unable to handle the message".

There is not concept of "unable to handle the message" in MQTT. Each side simply acknowledges receipt of a QoS1+ MESSAGE by sending a PUBACK packet back.

If you're asking about how to do request/response, MQTT is purely a publish/subscribe protocol. If you want request/response you have two basic options:

1. Roll your own request/response protocol on top of MQTT. Send a MESSAGE whose contents are the response to some specific request-style MESSAGE.
2. Use HTTP, which is a request/response protocol.

Are you asking how a server/broker would use this code? This library only contains an mqtt-client implementation and we don't have plans to build a broker.

[aquark]

I understand that mqtt doesn't allow the client to explicitly report failure to the broker, and that's not what I'm suggesting. Failure is implicit when the broker doesn't receive a PUBACK. E.g. if the client process were to die after receiving the message and before acknowledging it, we would say that it failed to process the message.

By "unable to handle the message" I mean that the client was unable to either fully process the message or store it for later processing. For example, the client may be acting as a broker for other services on a device or network, and the message is effectively not "received" unless the broker was able to store it or forward it and receive an acknowledgement in turn.

This is important for QoS 1 messages which must not be lost at any point in the chain of applications which process the message. Other mqtt client libraries allow the client application to dictate when the PUBACK is sent. For example, mqtt.js (and therefore the v1 AWS IoT JavaScript Device SDK) passes a callback to the client's handleMessage function which the consumer calls to acknowledge receipt of the message.

I suppose we could work around this by abruptly terminating the thread whenever a message handler encounters an error, but this is not always convenient, and may have unwanted side effects.

[aquark]

I have seen libraries which assume synchronous processing let the handler return true or false to indicate if the message should be acknowledged. The drawback of synchronous acknowledgement is that it limits the throughput of receiving messages. E.g. if the listener thread has to wait for a QoS 1 message to be written to disk, this is wasting time it could be processing QoS 0 messages. By allowing messages to be acknowledged asynchronously via a callback, the QoS 1 message can be passed to another thread to persist and acknowledge the message. This is also more convenient for applications which try to do all io asynchronously.

[graebm]

Ah, i follow now.
You would like a way for the application to control when/whether the PUBACK is sent for a received QoS1 message. I admit, this use-case escaped our consideration when designing the library.

I'll discuss this with my team, unfortunately I can't make any promises. Open an internal Amazon ticket if this is something you need addressed with priority.

[aquark]

You got it. Without this feature QoS 1 is kind of pointless, but we're able to work around it by handling acknowledgement at the application layer (the sender expects a confirmation message from the receiver and resends the message if it doesn't get one soon enough).