Introduce RETRY error handling strategy

Description

Currently error handlers can only decide to abort or continue the current flush cycle in case of a failure. Another means of dealing with failures is to retry the failed operation.

One could make the retry strategy to use configurable:

  • Retry n times

  • Exponential back-off with n steps and factor m

  • ...

onFailedGridDialectOperation() would return RETRY, letting the configured retry strategy take over.

As per the use cases from OGM-465:

  • UC-2.2: I want to retry the failed operation for certain exception types; If that succeeds, I want to continue, if that fails, I want to abort the further processing of the flush cycle
    Example: In case of a OgmDatastoreNotAvailableException I want to retry twice (my connection is a bit unstable); If it fails I want to give a file with applied changes to someone for manual checking / processing

  • UC-2.3: I want to alter and retry the failed operation for certain exception types; If that fails, I want to abort the further processing of the flush cycle
    Example:

Environment

None

Assignee

Unassigned

Reporter

Gunnar Morling

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Fix versions

Priority

Minor
Configure