Golang wrapper for RabbitMQ managed connections.
Version 1.0.0 and beyond 🚀.
This is an alternative library providing auto-reconnection support. It's been heavily inspired by other projects (listed in credits) and my previous experiments. The reason for a new project (instead of cloning/contributing to an existing one) is that internals may start to diverge too much from the original and risk non-adoption.
Please use the wiki page for a detailed list of how to get the most out of this library.
What I'd like this library to provide is:
- make use of the latest amqp091-go library; this is the up to date version building on streadway's original work
- be able to share a connection between multiple channels
- have connection and channels auto-recover (on infrastructure failure) via managers
- replace the internal logging with an alternative. Current thought is to have some buffered channel over which detailed events are submitted (non-blocking)
- have the topology defined by consumers and publishers. Once when creating and then during channels recovery (ephemeral queues/exchanges only)
- provide an optional callback to the caller space during recoveries. This supplements in a synchronous (blocking) mode the logging replacement mechanism.
- awaiting confirmation of the published events via deferred methods (PublishDeferredConfirm or PublishDeferredConfirmWithOptions together with AwaitDeferredConfirmation).
- consumers to accept user defined handlers for processing the received messages
- the consumer handlers to also allow batch processing (with support for partial fulfillment of QoS expectations based on a timeout)
- Bonus: optionally provide the users with access to the low level
amqp.Channel. Unsafe initially. Note: safety comes for free if using the slightly higher levelgrabbit.Channelwrappers.
- not interested in concurrency safety of the high level publisher and consumers. These are relatively cheap therefore use plenty as needed, instead of passing them across coroutines.
- wagslane from whom I got heavily inspired to do the sane parameters, topology maintenance and consumer handlers. Please browse and star his repository.
- Emir Ribic for his inspiring post that lead me to think about adding a resilience layer for the RabbitMQ client. You may want to read the full post
- gbeletti from whose project I might pinch a few ideas. Regardless of drawing inspiration or not, his version made for an interesting reading.