Use case for ExponentialBackOffPolicy?

[dkaminsky]

Wondering if there's a real use case for exponential back off policy. It's the only stateful backoff policy, and if it doesn't offer significant advantage over the fixed policy, I would argue that there was no reason to have separate BackOffPolicy/BackOffContext participants as opposed to adding:

void backOff(RetryContext context) throws RetryInterruptedException;

to the RetryPolicy interface, or even just having a "backOffInterval" field that specifies the back off time in seconds (0 for no back off).

[Dave Syer]

Exponential backoff is a common tachnique for avoiding deadlock (if two participants are trying to back off with fixed steps, they can lock together, but it is much less likely to happen if the interval increases exponentially). This is a lesson from ethernet / networking, but it was specifically requested and is used by a client.

Why is it important to eliminate the context?

[dkaminsky]

It just seems like it could be merged with retry policy easily enough. Trying to think of areas where the API can be trimmed per Greg's issue. Also, trying to create some documentation for retry policy it just seems like an extra wrinkle that could be simplified.

If stateful back off policy could be eliminated, you could just replace the whole back off policy paradigm with an integer property specifying the time to wait between retries.

Alternatively, if the backOff method is moved into the retry policy interface and backoff context is somehow folded into retry context (e.g. eliminate it completely and use getRetryCount() in the backOff method instead of keeping a separate context), we could easily eliminate backoff policy as a separate interface (and the related interruption exception would go away too). -- Not to mention eliminating the AbstractStateful/Stateless back off policy classes.