Description
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.
Attachments
Issue Links
- relates to
-
DBZ-6172 SQL Server Connector Throws Exceptions in its taskConfigs() Method
- Open