Open vishnureddy17 opened 6 months ago
If the queue implementation in autopaho is in a permanently failed state,
Could you please provide an example of a failed state? Messages really just move from the queue into the session (except with QOS0 where a failure to transmit over the network would lead to the messages being retried).
I guess we could add a callback that is called before retransmitting a message; this might be useful in other situations (i.e. a message might have a deadline and, should that time pass, it should not be retried).
Could you please provide an example of a failed state?
Hypothetically, what if the application is using a file-based queue and the underlying storage medium is disconnected or failed?
Or what if the user has a custom queue implementation that relies on a database connection but a connection is not able to be established?
Maybe the queue interface needs a way to signal a "permanant failure".
Hypothetically, what if the application is using a file-based queue and the underlying storage medium is disconnected or failed? Maybe the queue interface needs a way to signal a "permanant failure".
I'm open to suggestions on this but am not sure how far to go with this; if there is a hardware failure then I think that continually retrying may well be the right approach (when the issue is fixed things will start working again). I guess that adding an error callback might help users detect the issue.
One way that a user could deal with this is to implement their own queue, and handle errors how they see fit; this may mean that if an error is detected Peek
returns nil
until it's resolved (perhaps Wait
would retry every second). I think this might be a better option than us trying to come up with a one-size-fits-all solution within the main library.
If the
queue
implementation inautopaho
is in a permanently failed state,managePublishQueue()
will continue retrying indefinitely.Should there be some way for
queue
issues to be detected soautopaho
can quit and surface the issue to the user?