You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLDR; associate consumers with health checks to enable/disable them as the status of dependent services change
I haven't seen this implemented in a competing library, and it may be beyond the "slim" scope, but all the same it may be a feature that garners interest. It would certainly be useful in my environment.
Consumers often require different downstream services to fulfil their execution. One may need a specific database instance, another network storage, while a third may require a third party API (or a combination of services) to be available. When one of these dependencies become unavailable, the consumer needs to be resilient and handle the failure gracefully or fail successively before the message ends up in the dead letter queue.
If consumers were to be associated with the health checks of their dependent services, then they could be individually started/stopped on a health status change. Disabling only the impacted consumer(s) would ease the impact while allowing uneffected consumers to continue processing messages unimpeded.
A potential solution is to have a proxy sitting between MessageBusBase and the Consumers to intercept Start/Stop events while monitoring health checks (tags) to start/stop the consumer as appropriate.
The text was updated successfully, but these errors were encountered:
EtherZa
changed the title
[Host | Feature request] Toggle consumers by health check tag
[Host | Feature request] Toggle consumers by health check tag(s)
Apr 19, 2024
TLDR; associate consumers with health checks to enable/disable them as the status of dependent services change
I haven't seen this implemented in a competing library, and it may be beyond the "slim" scope, but all the same it may be a feature that garners interest. It would certainly be useful in my environment.
Consumers often require different downstream services to fulfil their execution. One may need a specific database instance, another network storage, while a third may require a third party API (or a combination of services) to be available. When one of these dependencies become unavailable, the consumer needs to be resilient and handle the failure gracefully or fail successively before the message ends up in the dead letter queue.
If consumers were to be associated with the health checks of their dependent services, then they could be individually started/stopped on a health status change. Disabling only the impacted consumer(s) would ease the impact while allowing uneffected consumers to continue processing messages unimpeded.
A potential solution is to have a proxy sitting between
MessageBusBase
and theConsumers
to interceptStart
/Stop
events while monitoring health checks (tags) to start/stop the consumer as appropriate.The text was updated successfully, but these errors were encountered: