Dynamic Adjustment of DBLE Thread Pools Without Restart

Background

In production, a DBLE instance may start with low traffic, but as load grows the default thread‑pool configuration (e.g., processors , backendProcessors ) can become a bottleneck, requiring multiple tuning cycles to reach optimal performance.

Previously, changing thread‑pool sizes required a restart, which was inflexible and could disrupt upstream services. Starting from DBLE 3.21.06.*, a non‑restart method is provided.

Command

update dble_information.dble_thread_pool set core_pool_size = 2 where name = 'BusinessExecutor';

Note:

Supported dynamic thread pools: businessExecutor , writeToBackendExecutor , processors (when usingAIO=0 ), backendProcessors (NIO), backendBusinessExecutor , complexQueryExecutor .

Dynamic adjustment is not supported for AIO‑mode processors and backendProcessors .

Due to JDK ThreadPoolExecutor’s scaling behavior, the new core_pool_size may not appear immediately in the table, but the pool will honor the change.

Although hot‑adjustment is possible, it is recommended not to modify pools during peak traffic to avoid unknown issues.

Principle Interpretation

External Queue + Thread Pool

DBLE adopts a classic Reactor multi‑thread model for high‑concurrency network I/O. The main Reactor thread accepts connections and hands them to sub‑reactor threads via an external queue; sub‑reactors register connections and forward data to worker threads through additional queues.

The worker thread pool then processes tasks and routes results back to the client or backend executors.

JDK Built‑in Thread Pool

DBLE leverages Java’s ThreadPoolExecutor . The pool separates task production and thread consumption, managing tasks via a producer‑consumer model. It supports direct execution, queuing, or rejection of tasks, and recycles idle threads.

In DBLE, businessExecutor and writeToBackendExecutor use external queues; processors and backendProcessors use external queues in NIO mode and AsynchronousChannelGroup in AIO mode; backendBusinessExecutor uses external queues in performance mode; complexQueryExecutor is directly scheduled by the pool.

Specific Implementation

Thread Pool

JDK’s ThreadPoolExecutor provides public setters such as setCorePoolSize . When the core size is increased, new workers are created on demand; when decreased, idle workers are interrupted and later reclaimed.

External Queue + Thread Pool

During expansion, newly created threads must be bound to the external queue so they can receive pending tasks. During contraction, idle threads are reclaimed, but for non‑resident threads a manual interrupt is needed to signal termination before the pool’s own shrink‑age logic takes effect.

Aftercare

IO threads ( processors , backendProcessors ) handle client and backend connections. When scaling up, new IO threads must start processing new requests; when scaling down, connections from the removed thread must be transferred to other IO threads.

DBLE implements this by first canceling connections on the thread to be removed, then re‑registering them on another thread, preferring the thread with the fewest connections for removal and the one with the most connections for re‑registration.

Summary

Since DBLE 3.21.06.*, thread‑pool parameters can be adjusted at runtime without restarting. Because DBLE combines JDK thread pools with external queues and IO connection handling, the dynamic command goes beyond simple JDK setters and includes extra steps to ensure smooth transition of IO threads.

Although no anomalies were observed in concurrency tests, it is advisable to perform adjustments under low load to ensure stable handover and lower resource consumption. Issues can be reported on the GitHub repository actiontech/dble for further improvement.

References

Understanding Reactor and Proactor models: https://cloud.tencent.com/developer/article/1488120

Java thread‑pool implementation and Meituan’s practice: https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html