https://devops-monk.com/tags/retry/Recent content in Retry on Devops MonkHugoen-usMon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-kafka/non-blocking-retries/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-kafka/non-blocking-retries/The Blocking Retry Problem DefaultErrorHandler retries by seeking back to the failed offset. While retrying, no other records from that partition are consumed — the partition is blocked. For a topic with high throughput, one slow retry can cause significant consumer lag. flowchart TD subgraph Blocking["Blocking Retry (DefaultErrorHandler)"] B1["poll() → [r50, r51, r52, r53]"] B2["process r50 ✓"] B3["process r51 ✗ — retry"] B4["wait 10s... retry r51 ✗"] B5["wait 20s... retry r51 ✗"https://devops-monk.com/tutorials/spring-kafka/retryable-exceptions/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-kafka/retryable-exceptions/Transient vs Permanent Failures Not every exception is worth retrying. Retrying a NullPointerException or a schema validation error wastes time and delays other records. Retrying a database timeout or a downstream HTTP 503 is exactly right — the error is temporary and will likely resolve. flowchart TD Ex["Exception in listener"] Q{"Transient?\n(DB timeout, HTTP 503,\nnetwork blip)"} Q -->|Yes| Retry["Retry with BackOff"] Q -->|No| Skip["Call recoverer immediately\n(no retries wasted)"] Retry -->|"still failing after\nmax retries"