Test was passing locally and in the CI as the start was very fast and
after the first start retriable wait condition wasn't met, so we
actually sleep and while the sleep we doesn't increment the counter
and the state is still `RESTARTING`. On slower machines when start
takes longer time and we don't wait, the test is actualy wrong.
The correct test either should remove last assert for `RESTARTING`
state or increase number of failures and add a sleep time after initial
start, so that there is no retry wait time.
This PR implements the later option.
- Implemented a dynamic solution for handling version changes in OpenTelemetry, using Java introspection to determine the correct interceptor class at runtime.
- Utilized a custom "ProducerInterceptor" to delegate logic based on the presence of specific OpenTelemetry classes.
- Removed direct usage of OpenTelemetry's internal API 'ConfigUtils'.
- Aligned solution with Debezium's aim of ensuring compatibility with Strimzi.
This update ensures a more robust handling of OpenTelemetry's version transitions.
- Changing the traceRecord method to be static. This avoids creating an instance on each call.
- Caching the results of isOpenTelemetryJavaagentEnable() and isOpenTelemetryApiEnable().
- Using isDebugEnabled() to avoid the costs of constructing strings when it's not necessary.
- Reorganizing some conditions to minimize the operations performed.
- Moving the static instances TEXT_MAP_PROPAGATOR, SETTER, and GETTER into the traceRecord method. This will prevent them from being held in memory when not in use.
* Try to start the connector in BaseSourceTask::start(). This is the
root cause of DBZ-6213 as EmbeddedEngine calls start() and assumes
it really tries to start the connector.
* Simplify the code by removing unnecessary checks.
We hypothesize that there could be a situation where we may be mining precisely
around the CURRENT_SCN and this may lead to situations where LGWR may not have
flushed all records for the same SCN before being mined by the connector.
