<commit_before>---
layout: pattern
title: Retry
folder: retry
permalink: /patterns/retry/
categories: other
tags:
  - java
  - difficulty-expert
  - performance
---

## Retry / resiliency
Enables an application to handle transient failures from external resources.

## Intent
Transparently retry certain operations that involve communication with external
resources, particularly over the network, isolating calling code from the 
retry implementation details.

![alt text](./etc/retry.png "Retry")

## Explanation
The `Retry` pattern consists retrying operations on remote resources over the 
network a set number of times. It closely depends on both business and technical
requirements: how much time will the business allow the end user to wait while
the operation finishes? What are the performance characteristics of the 
remote resource during peak loads as well as our application as more threads
are waiting for the remote resource's availability? Among the errors returned
by the remote service, which can be safely ignored in order to retry? Is the 
operation [idempotent](https://en.wikipedia.org/wiki/Idempotence)?

Another concern is the impact on the calling code by implementing the retry 
mechanism. The retry mechanics should ideally be completely transparent to the
calling code (service interface remains unaltered). There are two general 
approaches to this problem: from an enterprise architecture standpoint 
(**strategic**), and a shared library standpoint (**tactical**).

*(As an aside, one interesting property is that, since implementations tend to 
be configurable at runtime, daily monitoring and operation of this capability <commit_msg>Fix Retry pattern categories and tags<commit_after>---
layout: pattern
title: Retry
folder: retry
permalink: /patterns/retry/
categories: Other
tags:
  - Java
  - Difficulty-Expert
  - Performance
---

## Retry / resiliency
Enables an application to handle transient failures from external resources.

## Intent
Transparently retry certain operations that involve communication with external
resources, particularly over the network, isolating calling code from the 
retry implementation details.

![alt text](./etc/retry.png "Retry")

## Explanation
The `Retry` pattern consists retrying operations on remote resources over the 
network a set number of times. It closely depends on both business and technical
requirements: how much time will the business allow the end user to wait while
the operation finishes? What are the performance characteristics of the 
remote resource during peak loads as well as our application as more threads
are waiting for the remote resource's availability? Among the errors returned
by the remote service, which can be safely ignored in order to retry? Is the 
operation [idempotent](https://en.wikipedia.org/wiki/Idempotence)?

Another concern is the impact on the calling code by implementing the retry 
mechanism. The retry mechanics should ideally be completely transparent to the
calling code (service interface remains unaltered). There are two general 
approaches to this problem: from an enterprise architecture standpoint 
(**strategic**), and a shared library standpoint (**tactical**).

*(As an aside, one interesting property is that, since implementations tend to 
be configurable at runtime, daily monitoring and operation of this capability 
{'fraction_non_alphanumeric': 0.053007742703990474, 'fraction_numerical': 0.0, 'mean_word_length': 5.0413669064748206, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2797293', 'n_tokens_mistral': 786, 'n_tokens_neox': 767, 'n_words': 439}