Does Couchbase Java SDK 3.3.0's shutdown hook reliably release Netty EventLoopGroups under high connection churn in containerized deployments?

Answer

No. The automatic shutdown hook does not guarantee that all Netty EventLoopGroups are released when the process is terminated abruptly.

Likely explanation

The shutdown hook registers only on a graceful JVM shutdown (SIGTERM or Ctrl‑Break). In Kubernetes a pod may receive SIGKILL during termination, which bypasses the hook entirely, leaving EventLoopGroup threads and groups dangling.

Confirmed facts

• The Couchbase Java SDK 3.3.0 added a shutdown hook in ClusterEnvironment that calls Cluster.disconnect() on JVM exit.
• Netty releases EventLoopGroups only when the event‑loop threads finish; abrupt termination prevents this cleanup.
• EventLoopGroup leaks are hidden unless Netty leak detection is enabled with -Dio.netty.leakDetection.level=advanced.
• High connection churn can create many EventLoopGroups quickly, increasing the chance that some remain after an abrupt kill.

Steps to verify

1. Start the container with Netty leak detection enabled (add -Dio.netty.leakDetection.level=advanced to the JVM options).
2. Run the application under normal load, then send SIGTERM to the process; after the process exits, check that the number of active EventLoopGroups returns to zero or the baseline.
3. Terminate the container with SIGKILL (e.g., kubectl kill -s KILL ) and immediately inspect the Netty leak report or take a heap dump to see if any EventLoopGroups remain unreleased.
4. Ensure that every Cluster instance is explicitly disconnect()ed before the application shuts down, especially when creating and closing clusters rapidly.

Please confirm whether Netty leak detection is enabled (io.netty.leakDetection.level) in your container environment, as this determines whether you can reliably observe lingering EventLoopGroups after a SIGKILL termination.