| layout | title |
|---|---|
default |
Timeout |
{: .no_toc }
- TOC {:toc}
[Timeouts][Timeout] allow you to fail an execution with TimeoutExceededException if it takes too long to complete:
Timeout<Object> timeout = Timeout.of(Duration.ofSeconds(10));You can create a Timeout that [interrupts][interrupt] execution if it times out:
Timeout<Object> timeout = Timeout.builder(Duration.ofSeconds(10)).withInterrupt().build();If a cancellation is triggered by a Timeout, the execution is completed with TimeoutExceededException. See the [execution cancellation][execution-cancellation] page for more on cancellation and interruption.
When a Timeout is [composed][policy-composition] outside a RetryPolicy, a timeout occurrence will cancel any inner retries:
Failsafe.with(timeout).compose(retryPolicy).run(this::connect);When a Timeout is [composed][policy-composition] inside a RetryPolicy, a timeout occurrence will not automatically cancel any outer retries:
Failsafe.with(retryPolicy).compose(timeout).run(this::connect);When an async executions times out, Failsafe still waits until the execution completes, either through interruption or naturally, before recording a TimeoutExceededException. This avoids the risk of retrying while the original execution is still running, which ultimately could lead to numerous abandoned executions running in numerous threads.
[Timeouts][Timeout] support the standard [policy listeners][PolicyListeners] which can notify you when a timeout is exceeded:
builder.onFailure(e -> log.error("Connection attempt timed out", e.getException()));Or when an execution completes and the timeout is not exceeded:
builder.onSuccess(e -> log.info("Execution completed on time"));Since the [async integration][async-integration] methods involve external threads, which Failsafe has no knowledge of, these executions cannot be directly cancelled or interrupted by a Timeout. But, these executions can still [cooperate][cooperative-cancellation] with a Timeout cancellation.
{% include common-links.html %}