Class ExponentialBackOffRetryPolicy
- All Implemented Interfaces:
DescribableComponent,RetryPolicy
- Since:
- 4.2
- Author:
- Bert Laverman, Allard Buijze
-
Nested Class Summary
Nested classes/interfaces inherited from interface org.axonframework.messaging.core.retry.RetryPolicy
RetryPolicy.Outcome -
Constructor Summary
ConstructorsConstructorDescriptionExponentialBackOffRetryPolicy(long initialWaitTime) Initializes an exponential delay policy with giveninitialWaitTimein milliseconds. -
Method Summary
Modifier and TypeMethodDescriptionProvides the outcome for the policy given the failedmessagethat was dispatched and resulted in givenfailure.voiddescribeTo(ComponentDescriptor descriptor) Describe the properties ofthis DescribableComponentwith the givendescriptor.
-
Constructor Details
-
ExponentialBackOffRetryPolicy
public ExponentialBackOffRetryPolicy(long initialWaitTime) Initializes an exponential delay policy with giveninitialWaitTimein milliseconds.- Parameters:
initialWaitTime- the wait time for the first retry
-
-
Method Details
-
defineFor
public RetryPolicy.Outcome defineFor(@Nonnull Message message, @Nonnull Throwable failure, @Nonnull List<Class<? extends Throwable>[]> previousFailures) Description copied from interface:RetryPolicyProvides the outcome for the policy given the failedmessagethat was dispatched and resulted in givenfailure. ThepreviousFailuresrepresent a summary of previous failures that have occurred in previous attemps to send this message.- Specified by:
defineForin interfaceRetryPolicy- Parameters:
message- The message that failedfailure- The exception that occurred while dispatchingpreviousFailures- a summary of all previous failures- Returns:
- the outcome describing the expected rescheduling behavior
-
describeTo
Description copied from interface:DescribableComponentDescribe the properties ofthis DescribableComponentwith the givendescriptor.Components should call the appropriate
describePropertymethods on the descriptor to register their properties. The descriptor is responsible for determining how these properties are formatted and structured in the final output.Best Practices: As a general rule, all relevant fields of a
DescribableComponentimplementation should be described in this method. However, developers have discretion to include only the fields that make sense in the context. Not every field may be meaningful for description purposes, especially internal implementation details. Furthermore, components might want to expose different information based on their current state. The final decision on what properties to include lies with the person implementing thedescribeTomethod, who should focus on providing information that is useful for understanding the component's configuration and state.Example implementation:
public void describeTo(ComponentDescriptor descriptor) { descriptor.describeProperty("name", this.name); descriptor.describeProperty("enabled", this.enabled); descriptor.describeProperty("configuration", this.configuration); // A nested component descriptor.describeProperty("handlers", this.eventHandlers); // A collection }- Specified by:
describeToin interfaceDescribableComponent- Parameters:
descriptor- The component descriptor to describethis DescribableComponentn its properties in.
-