feat(restart-inbound): give the possibility to the developer to plan a restart of the connector in case of failure

[mathias-vandaele]

Description

Proposal of solution for the restart of inbound connector, not tested yet

Related issues

closes #3319

Checklist

• PR has a milestone or the no milestone label.

[sbuettner]

Hey @mathias-vandaele, the ticket contains an implementation suggestion: #3319 to re-use the existing cancellation mechanism. Would be interesting to understand why you see the need to introduce another method?

[mathias-vandaele]

Hey @mathias-vandaele, the ticket contains an implementation suggestion: #3319 to re-use the existing cancellation mechanism. Would be interesting to understand why you see the need to introduce another method?

@sbuettner everything still happens during the cancellation mechanism

@Override
 public void cancel(Throwable exception) {
   try {
     cancellationCallback.accept(exception);
   } catch (Throwable e) {
     LOG.error("Failed to deliver the cancellation signal to the runtime", e);
   }
   if (Objects.requireNonNull(exception) instanceof RestartException restartException) {
     reactivationCallback.accept(restartException.getBackoffTime());
   }
 }

A callback is declared in order to be executed after cancelation 👍

[johnBgood]

Does it make sense to reuse the ConnectorRetryException with the retries and backoff parameters?

[sbuettner]

@johnBgood Good idea although we would need a way to restart without defining the number of retries. We could add it. WDYT?

[johnBgood]

Yep, either that or we add the retries count to the context and when throwing the exception later we use this number, similar to how it's done for Outbound connectors.

[sbuettner]

@mathias-vandaele Ah, I was confused as I saw: reactivationCallback. Would it be simpler to re-use the existing cancellation callback and handle it in the consumer?

[johnBgood]

is it an issue if a Connector had an error? How do we handle multiple activation failure in this case?

[johnBgood]

any reason to use a single thread executor here?