-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add retry limit #234
Comments
Thanks for the suggestion. Currently there's already a way to customize the number of retries by setting a timeout in your RetryableTask or RetryableQuestion. It is used here in the Actor's The default timeout is 2 seconds (see here in It is now not clear to me what you want to achieve.
|
The idea is to be able to set a maximum amount retries. The proposed solution would give the option to choose whether to use a time based retry or an amount based retry behavior. |
- added variables retryLimit and retryNumber to Retryable.java - added function isNotSurpassingRetryLimit() to Retryable.java - added retry limit check to actor.does() and actor.checks() for RetryableTask & Retryable.Question #234
- added variables retryLimit and retryNumber to Retryable.java - added function isNotSurpassingRetryLimit() to Retryable.java - added retry limit check to actor.does() and actor.checks() for RetryableTask & Retryable.Question #234
In our team it would be preferred to limit the retries to a certain number.
Describe the solution you'd like
We would need two new variables in the Actor class. The variable maxRetries should be overridable.
Integer retryNumber = 0
Integer maxRetries = 0
Currently in the Actor.class the check looks like this:
if (question.acceptable(lastAnswer)) { reporters.forEach(reporter -> reporter.success(this, question, answer)); return answer; }
It would need to be replaced by a wrapper function:
if (question.acceptableWrapper(lastAnswer)) { reporters.forEach(reporter -> reporter.success(this, question, answer)); return answer; }
default boolean acceptableWrapper(A answer){ if(maxTries!=0 && retryNumber>maxRetries) return answer tryNumber++ acceptable(answer) }
We currently use our own code to do the same. This would be a cleaner approach and it adds a valuable feature to the framework.
The text was updated successfully, but these errors were encountered: