-
Notifications
You must be signed in to change notification settings - Fork 50
Description
When using OpenFeature, I noticed that the service takes longer than expected to shut down under certain conditions, such as when the HTTP port is already in use. Upon debugging, I found that this behavior is caused by OpenFeature's use of a ThreadPoolExecutor that creates non-daemon threads.
Non-daemon threads prevent the JVM from shutting down immediately, which can lead to delays and potentially block application termination. Additionally, the threads created by OpenFeature are named with the default pattern (e.g., pool-6-thread-1), making it difficult to identify their source during debugging or thread dumps.
Proposed Improvements
-
Switch to Daemon Threads:
- Update the
ThreadPoolExecutorto create daemon threads. Daemon threads allow the JVM to shut down immediately when the application exits, improving shutdown behavior.
- Update the
-
Use Descriptive Thread Names:
- Update the thread factory to assign descriptive names to threads, such as including the prefix
openfeature. This makes it easier to identify threads in thread dumps and logs.
- Update the thread factory to assign descriptive names to threads, such as including the prefix
Reasoning
- Faster Shutdowns: Non-daemon threads can cause the application to hang during shutdown until all threads are terminated. Switching to daemon threads resolves this issue.
- Debugging and Monitoring: Default thread names like
pool-6-thread-1provide no context about their origin, making debugging thread-related issues more challenging. Using descriptive names improves observability and troubleshooting. - Consistency: Aligning with best practices for thread management ensures better integration with user applications and reduces surprises during runtime.
Steps to Reproduce
- Start an application using OpenFeature.
- Simulate an error scenario, such as attempting to bind to an already-used HTTP port.
- Observe the delay in application shutdown.
- Inspect the thread dump and note the presence of non-daemon threads with default names (e.g.,
pool-6-thread-1).
Suggested Fix
- Update the
ThreadPoolExecutorinitialization to use a customThreadFactorythat:- Creates daemon threads (
thread.setDaemon(true)). - Assigns descriptive names to threads (e.g.,
openfeature-thread-{id}).
- Creates daemon threads (
References
- Java Thread Daemon Documentation
- Example of setting a custom
ThreadFactory:
ThreadFactory threadFactory = new ThreadFactoryBuilder()
.setNameFormat("openfeature-thread-%d")
.setDaemon(true)
.build();
ExecutorService executor = Executors.newFixedThreadPool(4, threadFactory);Additional Context
The issue was observed in the following version of OpenFeature: [Add version here].
If this behavior is intentional or there are constraints around making threads daemon, it would be helpful to document this in the project.
Impact
- Applications using OpenFeature may experience delayed shutdowns, especially during error scenarios.
- Debugging and monitoring thread-related issues are more difficult due to non-descriptive thread names.