Retry mechanism for data plane self-registration

[SaschaIsele]

Retry mechanism for data plane self-registration

This proposal aims to introduce a retry mechanism for the data plane self-registration.

Why we want this?

Faster Startup

If the control plane and the data plane are started simultaneously, it can occur that the data plane is done first.

In this case, the data plane tries to register itself but fails and goes in an error state.

The only solution is then to restart the data plane and wait for it to startup again.

A retry mechanism would alleviate this problem and make the startup faster and more predictable.

Affected Areas

Data plane self registration extension

Solution Proposal

Implement the retry mechanism which is able to retry the self registration, in case it fails the first time.

The retry mechanism should ideally have a configurable amount of retries, together with a retry delay.

[ndr-brt]

hi, it already exists, you can set it using the edc.core.retry properties:
https://eclipse-edc.github.io/Connector/autodoc/#connector-core

(by default it's 5 retries with a backoff starting from 500ms to 10s)

[SaschaIsele]

Was not aware of that, thanks.
The strange thing is though, that the dataplane directly went into the error state without any retries being logged (should have the default values for retries).
With error state I mean the .orElseThrow error in this snipped from DataplaneSelfRegistrationExtension.java.

dataPlaneSelectorService.addInstance(instance)
        .onSuccess(it -> {
            monitor.info("data plane registered to control plane");
            isRegistered.set(true);
        })
        .onFailure(f -> registrationError.set(f.getFailureDetail()))
        .orElseThrow(f -> new EdcException("Cannot register data plane to the control plane: " + f.getFailureDetail()));

Will have a look if it is a config issue or if there might be a bug.
If you have any ideas that come to mind I would also be thankful.

Edit:
As additional info, the control plane was up 5 seconds after the data plane so even if the retries were not logged, the exponential backoff time should not have been exceeded and one of the retries should have worked.

[ndr-brt]

logging retries is not something always desirable, if you want so, you can activate with configuration:
edc.core.retry.log.on.retry (please check the link I already sent for other related settings)