[PECOBLR-1408] [PECOBLR-1407] [PECOBLR-1409][PECOBLR-1411] Address telemetry code audit comments- part1

[samikshya-db]

Description

• 4 things that is improved with respect to telemetry :
  • Common object mapper across telemetry use-case (This is already thread safe and is expensive to create, i.e., good tor re-use)
  • MakeflushIntervalMillis config same across both telemetry clients (un-auth and auth)
  • Clear connection param cache when connection is closed : this was a memory leak before
  • Rather than creating a scheduledExecutor for each telemetry client, we share it across a factory.

Testing

• unit tests

Additional Notes to the Reviewer

• When the LAST connection to a host is closed, all pending telemetry events for that host are flushed across all prior connections (since they all shared the same TelemetryClient). i.e., If you have 5 connections to host-A, closing connections 1-4 does nothing (just decrements refCount). Only when you close connection 5 (the last one) does the flush occur, sending all accumulated telemetry from all 5 connections.

NO_CHANGELOG=true

[tejassp-db]

Connection ref count never decrements to zero. Should be fixed.

[tejassp-db]

Import com.databricks.jdbc.api.internal.IDatabricksConnectionContext into file. Use imports everywhere else as well..

[tejassp-db]

Is it possible for the context or connection uuid to be null? If both are always non-null, then we should enforce that in the code.

[samikshya-db]

I am skeptical of removing this because of ThreadLocal usage. Check the internal outage here : [Link]

[tejassp-db]

If a flush is slow, does it block flush for other statements?