Open MattBrittan opened 8 months ago
Carrying on discussion from #207 comment by @vishnureddy17
One note of caution is that the session may outlast the client instance (and I can't think of a good way of handling that!).
I think that's expected and necessary. As a user, I'd want to know when the publish was handled in the session (regardless of how many reconnections happened in the interim). In the solution you suggest, that would mean that the callback can potentially be called long after a particular client is dead.
Just to clarify; by "client instance" I meant the users program (rather than an instance of paho
/autopaho
). As the session can be stored on disk it's quite possible for the following to happen:
This raises a few questions:
My thought was always that if autopaho is in use then whatever notification method is selected should survive reconnections (these should be mostly hidden from the end user). We do also need to handle the situation where the session is lost (either due to Clean Start
or the session expiring) so probably want to be able to pass an error to the user when this happens.
Does the library provide a way to 'reregister' the callbacks (or whatever mechanism is used) when starting up?
This is an interesting issue. Currently, the SessionManager
interface doesn't expose a way to get the un-acknowledged messages that are in the session. So on an application restart, the application has no way of knowing which messages to re-register callbacks for. In other words, the application doesn't have knowledge of the messages that are pending. A similar problem exists for Queue
in autopaho.
Another issue is that even if the library provided a way to re-register callbacks, the user would have to know to register it before a connection is established since messages get resent in ConAckReceived
.
One possible solution is to have a callback for "orphaned" messages. However, this callback may be of little use since the callback is for publishes that the application has lost track of. This could perhaps be mitigated by including the re-sent packets as part of arguments supplied to the callback.
I think the problem of application restarts does not need to be solved immedidately. The solution for non-restarting applications is clearer, so it may be a better idea to solve that problem first.
My thought was always that if autopaho is in use then whatever notification method is selected should survive reconnections (these should be mostly hidden from the end user). We do also need to handle the situation where the session is lost (either due to Clean Start or the session expiring) so probably want to be able to pass an error to the user when this happens.
Agree with this.
Is your feature request related to a problem? Please describe.
When using async PUBLISH (i.e.
PublishWithOptions
withPublishMethod_AsyncSend
) it's not currently possible to determine when the message has been acknowledged (with QOS 2 messages it would be useful to know when both steps are complete).Describe the solution you'd like This was discussed a bit in issue #207 options include: