Question: Reconnect / retry mechanism

[DGuhr]

Hi 👋

I have a question, as I could not find a reconnect/retry mechanism for this client yet. Is it planned to add a reconnect / retry mechanism, or do you have an example of a consumer that has a reconnect/retry mechanism?

Context:

• we're using go-amqp to consume an amqp Queue indefinitely. From time to time there may be errors, mostly in non-prod environments, and we'd need to detect these and reconnect (at best with some sort of backoff algorithm, etc). We're currently implementing such a mechanism here: https://github.com/RedHatInsights/authz/blob/umb-reconnects/infrastructure/repository/messaging/UMBMessageBusRepository.go but somehow it feels like "this should be provided by the library, if possible".

I searched a bit for such thing, but all I found so-far is https://github.com/isayme/go-amqp-reconnect/blob/master/rabbitmq/rabbitmq.go which is for an amqp 0.9.1 client - and now due to the lack of results, I am questioning myself if we're completely on the wrong track here and there is a hidden mechanism we just don't know of 😅

Thanks!

[jhendrixMSFT]

@richardpark-msft and I have discussed this in the past, but nothing has been implemented in this module yet.

We do have retry/reconnect logic in our EventHubs and Service Bus modules. Here are a few links to the implementation in Service Bus. Note that some of the error conditions are specific to Service Bus, so if you're using a different broker then some of the logic won't apply.

Retry loop for sending/receiving a message
Predicate for determining recovery kind

Conceptually it's not that different from your retry/reconnect mechanism. Wait for a message and if an error is received, determine if it requires a reconnect (you should add *amqp.SessionError to your list of reconnect errors).

[richardpark-msft]

@DGuhr, I can't speak for why other libraries don't have retries, but some things in Azure this more complicated.

For instance:

• In Azure Service Bus, losing a link means you can't Accept() messages anymore (ie, those are all invalidated) so you have to attempt to settle via a "backup" route (not a general AMQP concept). So rather than have the AMQP stack waste operations we'd need to know immediately.
• In Azure Event Hubs when you restart a link you want to continue from where you left off, not start at the beginning or end. So the restart would need to send in an updated set of link parameters.
• We use a separate method for authentication that might require refreshing/reauthorizing credentials. So we'd need that to be called on every retry as well.

In the end most of our example designs just ended up having to be so general that it just ended up being more straightforward to handle it on a per-call-site basis.

BTW, if you do find that hidden mechanism PLEASE LET US KNOW. :)