Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 368189

Summary: WebSocketClientFactory should not manage external thread pool
Product: [RT] Jetty Reporter: Simone Bordet <simone.bordet>
Component: websocketAssignee: Simone Bordet <simone.bordet>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jetty-inbox
Version: 7.6.0.RC3   
Target Milestone: 7.5.x   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Simone Bordet CLA 2012-01-09 14:15:00 EST 
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.
Comment 1 Simone Bordet CLA 2012-01-09 14:37:06 EST 
Fixed.
Now WebSocketClientFactory correctly manages the ThreadPool parameter: if external, its lifecycle is not invoked.