spring-framework

Spring Framework

Tree: 46654a03fe

Sam Brannen 5cae769c2d Remove maxDuration/maxElapsedTime support from RetryPolicy When the core retry functionality was introduced, it had a built-in MaxRetryDurationPolicy. In #35058, that was migrated to a withMaxDuration() factory method, and in #35110 that was renamed to withMaxElapsedTime() (with a corresponding maxElapsedTime() method on the builder) in order to align with the maxElapsedTime feature of ExponentialBackOff. The latter also changed the semantics of the feature in the context of the RetryPolicy. However, @⁠Retryable does not provide maxElapsedTime support. In addition, the maxElapsedTime feature is a bit misleading, since it does not actually track CPU time or wall-clock time but rather only the sum of individual, accumulated back-off intervals/delays, which is likely not very useful. Furthermore, the maxElapsedTime will never apply to a zero-valued delay/interval. In light of the above, this commit removes the maxElapsedTime support from the built-in RetryPolicy. Users can still implement a custom BackOff strategy if they find they need some form of "max elapsed time" or "max duration". See gh-34716 See gh-35058 See gh-34529 See gh-35110 Closes gh-35144	6 months ago
..
src	Remove maxDuration/maxElapsedTime support from RetryPolicy	6 months ago
spring-core.gradle	Merge branch '6.2.x'	6 months ago

Sam Brannen 5cae769c2d Remove maxDuration/maxElapsedTime support from RetryPolicy

When the core retry functionality was introduced, it had a built-in
MaxRetryDurationPolicy. In #35058, that was migrated to a
withMaxDuration() factory method, and in #35110 that was renamed to
withMaxElapsedTime() (with a corresponding maxElapsedTime() method on
the builder) in order to align with the maxElapsedTime feature of
ExponentialBackOff. The latter also changed the semantics of the
feature in the context of the RetryPolicy.

However, @⁠Retryable does not provide maxElapsedTime support.

In addition, the maxElapsedTime feature is a bit misleading, since it
does not actually track CPU time or wall-clock time but rather only the
sum of individual, accumulated back-off intervals/delays, which is
likely not very useful. Furthermore, the maxElapsedTime will never
apply to a zero-valued delay/interval.

In light of the above, this commit removes the maxElapsedTime support
from the built-in RetryPolicy.

Users can still implement a custom BackOff strategy if they find they
need some form of "max elapsed time" or "max duration".

See gh-34716
See gh-35058
See gh-34529
See gh-35110
Closes gh-35144

6 months ago

src

Remove maxDuration/maxElapsedTime support from RetryPolicy

6 months ago

spring-core.gradle

Merge branch '6.2.x'

6 months ago