Community
Participate
Working Groups
Some of the WebSocketClientFactory take a ThreadPool parameter. The usual contract for dependencies is that if they are injected, then their lifecycle is managed externally. Unfortunately, WebSocketClientFactory wants to manage the ThreadPool passed in as constructor parameter, resulting in problems at shutdown, especially if the ThreadPool is shared. The typical example is when the ThreadPool is shared between two components; stopping the first one will stop also the ThreadPool, which hampers the functionality of the second: the second component may need to do some threaded work (such as closing connections) but it cannot because the ThreadPool is already stopped. WebSocketClientFactory should stick with the usual contract of managing the lifecycle only of internally created ThreadPools.
Fixed. Now WebSocketClientFactory correctly manages the ThreadPool parameter: if external, its lifecycle is not invoked.
