You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the general pattern for this client is to send all of the acknowledgements prior to the invocation of the registered publish handler. Unfortunately this means that if there is a failure after the ack is sent, but before the handler completes the Vert.x application using this API may not have had a chance to completely do work associating with fully accepting the message. For example, in our application we provide the option to persist the message (on disk), but currently we can't guarantee that if this fails to occur then the message will be redelivered (since the MQTT server will already have received the ack).
For starters it seems to me that the publish handler should be called prior to the acknowledgement. This would allow clients with synchronous work to perform that work prior to the sending of the ack.
However, in our case, since the work we need to do is asynchronous even that is insufficient (unless we block the handler, which we obviously don't want to do). So for our purposes we would prefer an option in the API which lets us control the sending of the acks so we can make sure they aren't sent until all the necessary work is completed.
The text was updated successfully, but these errors were encountered:
Vertx-MQTT version 3.6.2
Currently the general pattern for this client is to send all of the acknowledgements prior to the invocation of the registered publish handler. Unfortunately this means that if there is a failure after the ack is sent, but before the handler completes the Vert.x application using this API may not have had a chance to completely do work associating with fully accepting the message. For example, in our application we provide the option to persist the message (on disk), but currently we can't guarantee that if this fails to occur then the message will be redelivered (since the MQTT server will already have received the ack).
For starters it seems to me that the publish handler should be called prior to the acknowledgement. This would allow clients with synchronous work to perform that work prior to the sending of the ack.
However, in our case, since the work we need to do is asynchronous even that is insufficient (unless we block the handler, which we obviously don't want to do). So for our purposes we would prefer an option in the API which lets us control the sending of the acks so we can make sure they aren't sent until all the necessary work is completed.
The text was updated successfully, but these errors were encountered: