Add support for time threshold in retrypolicy

[failsafe-lib]

Add support for time threshold in retrypolicy

[jhalterman]

Furthermore the requst is in the third retry and already spent 9 seconds with retrying.
It would be great if the third retry wouldn't happen anymore since it will probably take more time then maxDuration and therefore will be interrupted.

So basically you'd want to track the average execution attempt time. And if according to that average, a subsequent execution attempt would exceed maxDuration, we should fail? If that sounds right, that's certainly doable, but I'm not sure how I feel about making guesses about execution times, particularly in scenarios where only 1 retry might be performed but the initial execution took a while - do we still retry? Should we? Maybe you can give me some example use cases for this?

In this scenario the application will end up in an undefined state, since the request to the other party might be succesfull but the app will never receive the response since maxDuration will take place.

I'm not sure what you mean here. I was thinking you meant that 2 retries would complete, in your example, but since the 3rd retry would take too long we'd simply fail instead of doing the 3rd retry. In this case, the caller/app would see a failure response (or exception).

[MALPI]

Probably it's quite hard to achieve but the point is the following:

You are right, the caller would throw exception due to timeout.

BUT the the callee would still get the request and process it.