Page History

...

Thread pools allow the system to service as many requests as it can comfortably sustain, instead of terminating all services when faced with a deluge of requests. They overcome these issues because the maximum number of worker threads that can be initiated and executed concurrently can be suitably controlled. Every worker accepts a Runnable or Callable<T> task and stores it in a temporary Channel such as a buffer or a queue until resources become available. Because threads in a thread pool can be reused, and efficiently added and removed from the Channel, there is minimal thread life-cycle management related overhead.

Noncompliant Code Example

This noncompliant code example demonstrates the Thread-Per-Message design pattern which fails to provide graceful degradation of service. The class RequestHandler provides a public static factory method so that callers can obtain its instance. Subsequently, the handleRequest() method is used to handle each request in its own thread.

class Helper {
  public void handle(Socket socket) {
    //... 		
  }	
}

final class RequestHandler {
  private final Helper helper = new Helper();
  private final ServerSocket server;

  private RequestHandler(int port) throws IOException {
    server = new ServerSocket(port);
  }
  
  public static RequestHandler getInstancenewInstance(int port) throws IOException {
    return new RequestHandler(port);
  }
  
  public void handleRequest() {
    new Thread(new Runnable() {
      public void run() {
        try {
          helper.handle(server.accept());
	} catch (IOException e) {
 	  // Forward to handler   
        }
      }
    }).start();
  }
  // Other methods such as for shutting down the thread pool and task cancellation ...
}

Compliant Solution

This compliant solution uses a _Fixed Thread Pool_ that places an upper bound on the number of concurrently executing threads. Tasks submitted to the pool are stored in an internal queue. This prevents the system from being overwhelmed when trying to respond to all incoming requests and allows it to degrade gracefully by serving a fixed number of clients at a particular time. \[[Tutorials 08|AA. Java References#Tutorials 08]\]

// class Helper remains unchanged

final class RequestHandler {
  private final Helper helper = new Helper();
  private final ServerSocket server;
  private final ExecutorService exec;
	 
  private RequestHandler(int port, int poolSize) throws IOException {
    server = new ServerSocket(port);
    exec = Executors.newFixedThreadPool(poolSize);
  }
	  
  public static RequestHandler getInstancenewInstance(int port, int poolSize) throws IOException {
    return new RequestHandler(port, poolSize);
  }
	  
  public void handleRequest() {	        
    exec.submit(new Runnable() {
      public void run() {
	try {
  	  helper.handle(server.accept());
	} catch (IOException e) {
          // Forward to handler						
        }
      }
    });
  }
}

...

The choice of the unbounded newFixedThreadPool may not always be the best. Refer to the API documentation for choosing between newFixedThreadPool, newCachedThreadPool, newSingleThreadExecutor and newScheduledThreadPool to meet specific design requirements.

Risk Assessment

Using simplistic concurrency primitives to process an unbounded number of requests may result in severe performance degradation, deadlocks and starvation, or exhaustion of system resources (denial-of-service).

Automated Detection

TODO

Related Vulnerabilities

Apache Geronimo 3838

References

\[[API 06|AA. Java References#API 06]\] [Interface Executor|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html]
\[[Lea 00|AA. Java References#Lea 00]\] Section 4.1.3 Thread-Per-Message and 4.1.4 Worker Threads
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Thread Pools|http://java.sun.com/docs/books/tutorial/essential/concurrency/pools.html]
\[[Goetz 06|AA. Java References#Goetz 06]\] Chapter 8, Applying Thread Pools
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 405|http://cwe.mitre.org/data/definitions/405.html] "Asymmetric Resource Consumption (Amplification)", [CWE ID 410|http://cwe.mitre.org/data/definitions/410.html] "Insufficient Resource Pool"

...