Handle permanent publish queue errors in Autopaho

[vishnureddy17]

If the queue implementation in autopaho is in a permanently failed state, managePublishQueue() will continue retrying indefinitely.

Should there be some way for queue issues to be detected so autopaho can quit and surface the issue to the user?

[MattBrittan]

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).

[vishnureddy17]

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".

[MattBrittan]

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.