Sharing the connection's executorService (which is sized based on metadataFetchThreadCount) for both metadata fetching and query execution background tasks (queryTaskExecutor) introduces a risk of Thread Starvation Deadlocks and performance interference.

Why this is an issue:

1. Deadlock Risk: Query execution background processing (e.g., in processJsonResultSet) concurrently submits multiple tasks to queryTaskExecutor (such as nextPageWorker and populateBufferWorker) which communicate via blocking queues. If metadataFetchThreadCount is configured to a low value (e.g., 1 or 2), or if the pool is saturated by concurrent metadata operations, these tasks can easily starve each other, leading to a deadlock where one task blocks on a queue while the other cannot be scheduled to consume from it.
2. Resource Contention: Heavy metadata operations (like getColumns or getTables which scan multiple datasets in parallel) can saturate the shared pool, causing query execution background tasks to experience significant scheduling delays.
3. Confusing Configuration: The metadataFetchThreadCount property is conceptually intended to control the parallelism of metadata retrieval, but it now implicitly caps the throughput of query execution background processing.

Recommendation:

Consider keeping a separate, dedicated bounded ExecutorService for query execution tasks (e.g., a bounded thread pool with a safe default size and defined maximum size), or ensure that the connection-scoped executor has a guaranteed minimum size and separate queues/pools to prevent starvation. Avoid using unbounded thread pools like Executors.newCachedThreadPool() to prevent resource exhaustion.

Checking queueSize % 10 == 0 to trigger a warning can lead to severe log flooding in high-throughput scenarios.

If the thread pool queue size fluctuates frequently around a multiple of 10 (e.g., bouncing between 9 and 10), a warning will be logged on almost every task submission. This can degrade performance due to logging overhead and clutter the application logs.

Recommendation:

Instead of a simple modulo check on every submission, consider using a rate-limiting mechanism for this warning (e.g., logging at most once every few seconds/minutes), or only log when the queue size crosses specific high-watermark thresholds (and log an info/debug message when it goes back down).

If awaitTermination is interrupted, it throws an InterruptedException which will bypass the subsequent shutdownNow() call. This can leave running tasks active and cause thread/resource leaks.

Recommendation:

Use the standard robust shutdown pattern to ensure shutdownNow() is always called even if the wait is interrupted, and properly restore the interrupted status.

      if (this.executorService != null) {
        this.executorService.shutdown();
        try {
          if (!this.executorService.awaitTermination(10, TimeUnit.SECONDS)) {
            this.executorService.shutdownNow();
          }
        } catch (InterruptedException e) {
          this.executorService.shutdownNow();
          Thread.currentThread().interrupt();
        }
      }