Step 3 — Surviving failure
A retry ladder that does not block the queue, dead letters, and replaying them.
Run it
One command, whichever language you came for. The image carries the
toolchain, the library and RabbitMQ; the management UI is on http://localhost:15672 (guest/guest)
while it runs, and --keep holds it open afterwards.
docker run --rm -p 15672:15672 ghcr.io/acemq-company/acemq-tutorials-java:0.7.15 step 3
docker run --rm -p 15672:15672 ghcr.io/acemq-company/acemq-tutorials-python:0.7.12 step 3
docker run --rm -p 15672:15672 ghcr.io/acemq-company/acemq-tutorials-ruby:0.7.14 step 3
docker run --rm -p 15672:15672 ghcr.io/acemq-company/acemq-tutorials-dotnet:0.7.13 step 3
docker run --rm -p 15672:15672 ghcr.io/acemq-company/acemq-tutorials-go:0.9.9 step 3Side by side
| Java | Python | Ruby | .NET | Go | |
|---|---|---|---|---|---|
| Example | 03-retries-and-dead-letters04-replay |
02-retries-and-dead-letters04-replay |
02-retries-and-dead-letters05-replay |
02-retries-and-dead-letters-csharp04-replay-csharp |
02-retries-and-dead-letters04-replay |
| Tutorial: surviving failure | Java | Python | Ruby | .NET | Go |
| Reliability | Java | Python | Ruby | .NET | Go |
Java
acemq-java-amqp 0.7.15, acemq-java-amqp-examples
examples-v0.7.15.
basic/03-retries-and-dead-letters
What happens when a handler fails. Three scenarios in one run: a failure that recovers, one that never does, and one that was never going to.
basic/04-replay
The other half of dead-lettering. Capturing a failed message is easy; this is getting it back once the cause is fixed.
Python
acemq-python-amqp 0.7.12, acemq-python-amqp-examples
examples-v0.7.12.
basic/02-retries-and-dead-letters
Three payments through one queue, and three different endings from one policy.
basic/04-replay
Dead-lettered invoices put back one tenant at a time, and the rest afterwards.
Ruby
acemq-ruby-amqp 0.7.14, acemq-ruby-amqp-examples
examples-v0.7.14.
basic/02-retries-and-dead-letters
Two charges: one whose acquirer keeps timing out, and one on a card that has been reported stolen. The first is retried until the policy runs out; the second gives up immediately. Both end on the dead-letter queue, with the reason written down.
basic/05-replay
A dead-letter queue with six invoices on it, of which three were broken by one tenant's currency converter. The fix goes out, and they go back through — some of them, in stages, with a count of what moved and what did not.
.NET
acemq-dotnet-amqp 0.7.13, acemq-dotnet-amqp-examples
examples-v0.7.13.
basic/02-retries-and-dead-letters-csharp
One payment whose handler always fails, retried on a fixed policy until the policy runs out, and then moved to a dead-letter queue with its id and its history intact — the attempt counter is the thing to watch, because it is the one number a broker on its own would get wrong.
basic/04-replay-csharp
Three invoices dead-lettered while a downstream service is down, then — once the fix is deployed for one tenant only — the two that belong to that tenant replayed from the dead-letter queue into the work queue, and the third left exactly where it was: dead-lettering is only half the story, and this is the other half.
Go
acemq-go-amqp 0.9.9, acemq-go-amqp-examples
examples-v0.9.9.
basic/02-retries-and-dead-letters
A payment handler that always fails, retried three times under a fixed policy and then dead-lettered with its history intact — followed by a second payment whose error is marked fatal, which skips the retries and goes straight to the dead-letter queue.
basic/04-replay
Three invoices sit on a dead-letter queue after an outage, and
patterns.Replay puts them back on their work queue in two
stages: first only one tenant's, chosen by a filter, while the other
tenant's invoice stays where it was, and then the rest — each one
handled exactly once.