Step 3 — Surviving failure

A retry ladder that does not block the queue, dead letters, and replaying them.

← step 2 · step 4 →

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 3

Side by side

Java Python Ruby .NET Go
Example 03-retries-and-dead-letters
04-replay
02-retries-and-dead-letters
04-replay
02-retries-and-dead-letters
05-replay
02-retries-and-dead-letters-csharp
04-replay-csharp
02-retries-and-dead-letters
04-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.