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
Currently, webhook messages whose HTTP call fails are consumed and requeued from/to RabbitMQ continuously. Doing so wastes a full CPU core for nothing. A less costly approach would be to use the dead-letter mechanism RabbitMQ provides.
Here is the general idea:
After each ballot, a webhook message is enqueued into the webhook queue.
The webhook worker consumes these messages in order and tries to call the associated remote server.
It the call fails, the worker rejects the webhook message.
Rejected messages are automatically routed to an isolation queue with no consumer.
After a certain amount of time, isolated messages are automatically sent back to the webhook queue.
The message can be rejected and delayed this way many times.
When the webhook call succeeds, the worker acknowledges the message. Done.
If the message becomes too old, the worker can silently acknowledge it to make it disappear from the queue.
This mechanism requires subtle configuration that I will describe here once I manage to have working POC.
The text was updated successfully, but these errors were encountered:
Currently, webhook messages whose HTTP call fails are consumed and requeued from/to RabbitMQ continuously. Doing so wastes a full CPU core for nothing. A less costly approach would be to use the dead-letter mechanism RabbitMQ provides.
Here is the general idea:
This mechanism requires subtle configuration that I will describe here once I manage to have working POC.
The text was updated successfully, but these errors were encountered: