It appears that variable RECONFIGURE_CONNECTOR_TASKS_BACKOFF_MS is fixed and hard-coded in Connect:
private static final long RECONFIGURE_CONNECTOR_TASKS_BACKOFF_MS = 250;
private void reconfigureConnectorTasksWithRetry(long initialRequestTime, final String connName) {
reconfigureConnector(connName, (error, result) -> {
// If we encountered an error, we don't have much choice but to just retry. If we don't, we could get
// stuck with a connector that thinks it has generated tasks, but wasn't actually successful and therefore
// never makes progress. The retry has to run through a DistributedHerderRequest since this callback could be happening
// from the HTTP request forwarding thread.
if (error != null) {
if (isPossibleExpiredKeyException(initialRequestTime, error)) {
log.debug("Failed to reconfigure connector's tasks ({}), possibly due to expired session key. Retrying after backoff", connName);
} else {
log.error("Failed to reconfigure connector's tasks ({}), retrying after backoff:", connName, error);
}
addRequest(RECONFIGURE_CONNECTOR_TASKS_BACKOFF_MS,
() -> {
reconfigureConnectorTasksWithRetry(initialRequestTime, connName);
return null;
}, (err, res) -> {
if (err != null) {
log.error("Unexpected error during connector task reconfiguration: ", err);
log.error("Task reconfiguration for {} failed unexpectedly, this connector will not be properly reconfigured unless manually triggered.", connName);
}
}
);
}
});
}
This enhancement would expose this property generically for all connector types and make it configurable via property or environment driven configuration.
- relates to
-
DBZ-6172 SQL Server Connector Throws Exceptions in its taskConfigs() Method
-
- Closed
-