-
Notifications
You must be signed in to change notification settings - Fork 297
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
Issue while using Timeout #255
Comments
I answered on SO.
…On Tue, Jun 16, 2020 at 8:18 AM ke7insud ***@***.***> wrote:
Hi
I have tried to post the question on StackOverflow but didn't get the
reply, so I am trying here also.
https://stackoverflow.com/questions/62317279/jodah-failsafe-library-timeout-is-taking-longer-then-expected
Can you please go through it and let me know what am I doing wrong
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#255>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADI7HIUZS3H53GDNORD3KTRW4FEDANCNFSM4N7JMO6A>
.
|
@whiskeysierra I think it's slightly confusing that the Timeout policy is completely ignored for blocking calls - maybe a more desirable behavior would be to have a precondition in Preconditions.checkState(
policies.stream().noneMatches(PolicyUtils::isTimeout),
"Please use .withMaxDuration(...) instead of a timeout when using a blocking method like get(...). "
+ "Note that .withMaxDuration will not interrupt execution")` or at least Also, if the evaluation of the timeout policy is scheduled on a different thread than the thread that executes the blocking call, that different thread could in theory interrupt the thread executing the blocking call. Anyways, leaving that aside, I'm also having some issues with Timeouts with RetryPolicy<Boolean> retryPolicy = new RetryPolicy<Boolean>()
.handleResultIf(retry -> retry)
.withMaxAttempts(-1);
Timeout<Boolean> timeout = Timeout.<Boolean>of(Duration.ofSeconds(1))
.withCancel(true)
.onFailure($ -> System.out.println("failure"))
.onSuccess($ -> System.out.println("success"));
Failsafe
.with(retryPolicy, timeout)
.getAsync(ctx -> !ctx.isCancelled())
.get(); This hangs forever (constantly printing "success"), while I would expect the timeout to cause the context to become canceled after 1 second, thus completing the future. Am I missing something? |
Answering second part first, which will lead to a response to the first part. Some of this probably belongs on StackOverflow.
Several things, I believe. From the way you wrote the code, I think you wanted to have the task repeat under a retry policy and have the timeout apply to the repeated execution. For that you need to change the order of the policies from But why does it behave the way it does with the policies in the order Most directly, the If you tweak your code as follows to simulate some work during the task execution, it repeatedly fails rather than repeatedly succeeding (I limited the attempts to 3 to avoid the infinite loop): ...
.withMaxAttempts(3);
...
Failsafe
.with(retryPolicy, timeout)
.getAsync(ctx -> {
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException ex) {
// XXX swallow exception; bad policy in practice
}
return !ctx.isCancelled();
})
.get(); This code prints Secondly, the argument to ...
.withCancel(CAN_INTERRUPT)
...
Failsafe
.with(retryPolicy, timeout)
.getAsync(ctx -> {
boolean cancelled = false;
boolean interrupted = false;
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException ex) {
// XXX swallow exception; bad policy in practice
interrupted = true;
}
cancelled = ctx.isCancelled();
System.out.printf("cancelled=%s, interrupted=%s%n", cancelled, interrupted);
return !cancelled;
})
.get(); With
When
If you comment out the
Perhaps surprisingly, it makes no difference what value is returned by the task. That's because the retry policy above uses .handleIf((retry, f) -> retry != null && retry) Also, and here's the beginning of a response to the first part of your comment:
Timeout is not completely ignored for blocking calls. @whiskeysierra wrote on SO:
And that's a reasonable rule of thumb, but in this case, changing
Note that, as described above, whether interruption is used depends on the argument passed to But even using |
For posterity, in addition to what @Tembrel mentioned, I should point out that the docs discuss cooperative cancellation and interruption, which can be used with either sync or async executions: https://failsafe-lib.github.io/execution-cancellation/#handling-cancellation Feel free to re-open this issue if needed. |
Hi
I have tried to post the question on StackOverflow but didn't get the reply, so I am trying here also.
https://stackoverflow.com/questions/62317279/jodah-failsafe-library-timeout-is-taking-longer-then-expected
Can you please go through it and let me know what am I doing wrong
The text was updated successfully, but these errors were encountered: