Advice on channel and connection error handling

[chill-cod3r]

I feel like this might be obvious to lots of people who would use this package, however I have seen this be a painful thing in codebases in the past. The amqplib doesn't do much in error handling, and I see this package wrapping around it to provide (imo) a really nice and clean API for subscribing and publishing to messages and topics. That being said, I worry that this package may suffer from the same issues as the core amqplib which basically leaves all reconnect logic up to the implementor - which always feels "boilerplatey" and less elegant than it should be (probably speaks to my lack of knowledge on handling the amqp protocol elegantly from a clientside implementation - which is why I'm asking this here to gain more perspective on that! 🤣 )

Just for a little background on my frame of reference, two packages I've used in the past are amqplib-plus and rascal - but they also don't have as "slick" of an API as this package.

All that being said - what is the best way to handle "global" connection errors and connection / channel retry logic with this package implementation? Is there a "write your own reconnect / retry" logic mentality here or is there some other strategy people are using? Thanks in advance for any helpful information someone can offer :)

[mateodelnorte]

In general, I've always subscribed to these notions:

1. Services you write should be relatively small and specific to one or very few purposes
2. By and large, services should crash hard upon unexpected errors and restart
3. An external system should manage the life cycle of the service to enact restart policy

So, how does that play with building services with servicebus? If a service has a connection error, crash hard and restart. You can either continually restart or restart with incremental backoff waits between. Since we're dealing with queue based systems, this simple behavior will lend you a self-healing system. You services will come online, connect to rabbitmq (or fail and restart this process), and dequeue messages upon connection. If you ensure your message handler code is transactionally complete (incoming messages aren't dequeued until outgoing messages are sent) and you design your system to be idempotent wherever possible, you will end up with an extremely reliable system.

[chill-cod3r]

This is 100% the complete information I was looking for. Thank you.

[mateodelnorte]

Cheers!

One correction to my notes above: messages aren't acknowledged until your operation is transactionally complete.

[chill-cod3r]

Ah nice, I kind of assumed that's what you meant 👍

On another note, (I may be missing something obvious here) but what is the difference between this package and the https://github.com/servicebus/rabbitbus @servicebus one? At a glance the documentation pages are the same. Do you recommend using one over the other if using rabbitmq as a message broker?

[mateodelnorte]

@patrickleet is in the middle of a refactor such that we can move servicebus to the new org, from my personal. We’ve got a couple decisions to make before we can finalize. Either will work fine.

On Sun, Jul 26, 2020 at 10:52 PM John Wolfe notifications@github.com wrote:

Ah nice, I kind of assumed that's what you meant 👍

On another note, (I may be missing something obvious here) but what is the difference between this package and the https://github.com/servicebus/rabbitbus @servicebus https://github.com/servicebus one? At a glance the documentation pages are the same. Do you recommend using one over the other if using rabbitmq as a message broker?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/mateodelnorte/servicebus/issues/158#issuecomment-664104830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHOX5277JDFBVTVTGCZDDR5T2WVANCNFSM4PHUGZ3A .