java.util.function.Supplier<RetryPolicy>@FunctionalInterface public interface RetryPolicy extends java.util.function.Supplier<RetryPolicy>
AbstractSource.
When an AbstractSource attempts to load the underlying data it uses a
RetryPolicy to govern if and how it retries the load operation in
case of errors.
The execute(java.util.function.Supplier) method of each policy
implementation must perform at least one attempt to load the data, even if it
chooses not to retry in case of errors.
| Modifier and Type | Method | Description |
|---|---|---|
default boolean |
cancel(boolean mayInterruptIfRunning) |
Cancels the current use of the retry policy.
|
<T> T |
execute(java.util.function.Supplier<T> call) |
Invokes the provided
Supplier to read the source data and returns
that data. |
static RetryPolicy |
from(Config metaConfig) |
Constructs a
RetryPolicy from meta-configuration. |
default RetryPolicy |
get() |
static RetryPolicy from(Config metaConfig) throws ConfigMappingException, MissingValueException
RetryPolicy from meta-configuration.
As described with ConfigSource.from(Config), the config system
can load ConfigSources using meta-configuration, which supports
specifying retry policies. The
built-in retry policies and custom ones are
supported. (The support is tightly connected with
AbstractSource extensions and
will not be automatically provided by any another config source
implementations.)
The meta-configuration for a config source can set the property
retry-policy using the following nested properties:
type - name of the retry policy implementation.
| Name | Policy | Properties |
|---|---|---|
repeat |
Tries to load at regular intervals until the retry count reaches
retries. See RetryPolicies.repeat(int), and
RetryPolicies.Builder for details on the properties. |
|
class - fully qualified class name of custom retry policy
implementation or a builder class that implements a build()
method that returns a RetryPolicy.
type or class to
indicate a retry policy but not both. If both appear the config system
ignores the class setting.
See ConfigSource.from(Config) for example of using built-in retry
policies.
The implementation class should define a Java bean property for each
meta-configuration property it needs to support. The config system uses
ConfigMappers to convert the text in the
meta-configuration into the correct Java type and then assigns the value
to the correspondingly-named Java bean property defined on the custom
policy instance. See the built-in mappers defined in
ConfigMappers to see what Java types are
automatically supported.
metaConfig - meta-configuration used to initialize returned retry
policy instance from.metaConfigMissingValueException - in case the configuration tree does not
contain all expected sub-nodes required by the mapper implementation to
provide instance of Java type.ConfigMappingException - in case the mapper fails to map the
(existing) configuration tree represented by the supplied configuration
node to an instance of a given Java type.ConfigSources.load(Supplier[]),
ConfigSources.load(Config)<T> T execute(java.util.function.Supplier<T> call)
Supplier to read the source data and returns
that data.
The implementation of this method incorporates the retry logic.
T - result typecall - supplier of TSupplierdefault boolean cancel(boolean mayInterruptIfRunning)
Implementations should correctly handle three cases:
cancel invoked when no invocation of execute is in
progress,cancel invoked when an invocation of execute is
active but no attempted load is actually in progress (e.g., a prior
attempt failed and the retry policy is waiting for some time to pass
before trying again), andcancel invoked while a load attempt is in progress.mayInterruptIfRunning - whether an in-progress load attempt should
be interruptedfalse if the task could not be canceled, typically
because it has already completed; true otherwisedefault RetryPolicy get()
get in interface java.util.function.Supplier<RetryPolicy>Copyright © 2018, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms.