feat: ISSUE-228 random - document as Jitter (#376)

* feat: ISSUE-228 random - document as Jitter

Signed-off-by: liran2000 <liran2000@gmail.com>

* fix build format

Signed-off-by: liran2000 <liran2000@gmail.com>

* Decapitalize jitter.

---------

Signed-off-by: liran2000 <liran2000@gmail.com>
Co-authored-by: Gary Russell <grussell@vmware.com>

README.md

@@ -337,7 +337,7 @@ back off with an exponentially increasing wait period, to avoid two retries gett
 lock step and both failing (a lesson learned from Ethernet). For this purpose, Spring
 Retry provides `ExponentialBackoffPolicy`. Spring Retry also provides randomized versions
 of delay policies that are quite useful to avoid resonating between related failures in a
-complex system.
+complex system, by adding jitter.
 
 ## Listeners
 

src/main/java/org/springframework/retry/annotation/Backoff.java

@@ -116,8 +116,8 @@ public @interface Backoff {
 
 	/**
 	 * In the exponential case ({@link #multiplier()} > 0) set this to true to have the
-	 * backoff delays randomized, so that the maximum delay is multiplier times the
-	 * previous delay and the distribution is uniform between the two values.
+	 * backoff delays randomized with jitter, so that the maximum delay is multiplier
+	 * times the previous delay and the distribution is uniform between the two values.
 	 * @return the flag to signal randomization is required (default false)
 	 */
 	boolean random() default false;

src/main/java/org/springframework/retry/backoff/ExponentialRandomBackOffPolicy.java

@@ -26,7 +26,8 @@ import org.springframework.retry.RetryContext;
  * that chooses a random multiple of the interval that would come from a simple
  * deterministic exponential. The random multiple is uniformly distributed between 1 and
  * the deterministic multiplier (so in practice the interval is somewhere between the next
- * and next but one intervals in the deterministic case).
+ * and next but one intervals in the deterministic case). This is often referred to as
+ * jitter.
  *
  * This has shown to at least be useful in testing scenarios where excessive contention is
  * generated by the test needing many retries. In test, usually threads are started at the