Page History

The Many programs must address the problem of handling a series of incoming requests. One simple concurrency strategy is the Thread-Per-Message design is the simplest concurrency technique wherein a thread is created for each incoming request. The benefits of creating a new thread to handle each request should outweigh the corresponding thread creation overheads. This design is generally recommended over sequential executions for time pattern, which uses a new thread for each request [Lea 2000a]. This pattern is generally preferred over sequential executions of time-consuming, I/O-bound, session-based, or isolated tasks.

On the other hand, there can be several disadvantages of this design such as thread creation overhead in case of frequent or recurring requests, significant processing overhead, resource exhaustion of threads (leading to {{OutOfMemoryError}}), thread scheduling and context switching overhead \[[Lea 00|AA. Java References#Lea 00]\].   

An attacker can cause a denial of service However, the pattern also introduces overheads not seen in sequential execution, including the time and resources required for thread creation and scheduling, for task processing, for resource allocation and deallocation, and for frequent context switching [Lea 2000a]. Furthermore, an attacker can cause a denial of service (DoS) by overwhelming the system with too many requests , all at once. Instead of degrading gracefully, causing the system goes down abruptly, resulting in an availability issue. Thread pools allow the system to service as many requests as it can comfortably sustain, instead of stopping all services when faced to become unresponsive rather than degrading gracefully. From a safety perspective, one component can exhaust all resources because of an intermittent error, consequently starving all other components.

Thread pools allow a system to limit the maximum number of simultaneous requests that it processes to a number that it can comfortably serve rather than terminating all services when presented with a deluge of requests. From the safety point of view, it is possible for one component to exhaust all resources because of some intermittent error, starving all others from using them.Thread Pools Thread pools overcome these issues as by controlling the maximum number of worker threads that can be initiated and executed simultaneously can be suitably controlled. Every worker accepts a Runnable object from a request execute concurrently. Each object that supports thread pools accepts a Runnable or Callable<T> task and stores it in a temporary Channel like a buffer or a queue until resources become available. Because threads are Additionally, thread life-cycle management overhead is minimized because the threads in a thread pool can be reused and can be efficiently added to the Channel, most of the thread creation overhead is also eliminatedor removed from the pool.

Programs that use multiple threads to service requests should—and programs that may be subjected to DoS attacks must—ensure graceful degradation of service during traffic bursts. Use of thread pools is one acceptable approach to meeting this requirement.

Noncompliant Code Example (Thread-Per-Message)

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

class Helper {
  public void handle(StringSocket requestsocket) {
    // ... 		
  }	
}

final class GetRequestRequestHandler {
  private final Helper hhelper = new Helper();
  String requestprivate final ServerSocket server;

  private public synchronized String accept()RequestHandler(int port) throws IOException {
    Stringserver data = "Read data from pipe"new ServerSocket(port);
  }

  //public Readstatic theRequestHandler request data, else blocknewInstance() throws IOException {
    return data; new RequestHandler(0); // Selects next available port
  }

  public void handleRequest() {
    while(true) {
      request = accept();
      new Thread(new Runnable() {
        public void run() {
           h.handle(request);try {
        }
      }).start();
    }
  }
}

Compliant Solution

This compliant solution uses a _Fixed Thread Pool_ that places an upper bound on the number of simultaneously executing threads. Tasks submitted to the pool are stored in an internal queue. This prevents the system from getting 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 GetRequest {
  final Helper h = new Helper();
  String request;
  final int NoOfThreads = 200; // Maximum number of threads allowed in pool
  final Executor exec;
 
  GetRequest() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);	  
  }

  public synchronized String accept(helper.handle(server.accept());
          } catch (IOException e) {
    String data = "Read data from pipe";
    // ReadForward theto requesthandler
 data, else block
    return data;
  }

  public void handleRequest() {
    while(true) {}
      request = accept();
      exec.execute(new Runnable() {
        public void run() {
          h.handle(request}).start();
        }
      });
    }
  }
}

unmigratedThe thread-wiki-markup

According to the Java API \[[API 06|AA. Java References#API 06]\] documentation for the {{Executor}} interface:

Wiki Markup
\[The Interface {{Executor}} is\] An object that executes submitted {{Runnable}} tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An {{Executor}} is normally used instead of explicitly creating threads.

Noncompliant Code Example

There are some problems associated with the incorrect use of the Executor interface. For one, tasks that depend on other tasks should not execute in the same thread pool. A task that submits another task to a single threaded Executor remains blocked until the results are received whereas the second task may have dependencies on the first task. This constitutes a deadlock.

This noncompliant code example shows a _thread starvation deadlock_. This situation not only occurs in single threaded Executors, but also in those with large Thread Pools. This can happen when all the threads executing in the pool are blocked on tasks that are waiting on the queue. A blocking operation within a subtask can also lead to unbounded queue growth. \[[Goetz 06|AA. Java References#Goetz 06]\] 

per-message strategy fails to provide graceful degradation of service. As threads are created, processing continues normally until some scarce resource is exhausted. For example, a system may allow only a limited number of open file descriptors even though additional threads can be created to serve requests. When the scarce resource is memory, the system may fail abruptly, resulting in a DoS.

Compliant Solution (Thread Pool)

This compliant solution uses a fixed thread pool that places a strict limit on the number of concurrently executing threads. Tasks submitted to the pool are stored in an internal queue. Storing tasks in a queue prevents the system from being overwhelmed when attempting to respond to all incoming requests and allows it to degrade gracefully by serving a fixed maximum number of simultaneous clients [Java Tutorials].

// class Helper remains unchanged

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

// Field password is defined in class InitialHandshake
class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocketserver;
  private final ExecutorService poolexec;

  publicprivate NetworkServerRequestHandler(int port, int poolSize) throws IOException {
    serverSocketserver = new ServerSocket(port);
    poolexec = Executors.newFixedThreadPool(poolSize);
  }
 
  public voidstatic RequestHandler runnewInstance(int poolSize) {
    try  { 
      // Interdependent tasks
      pool.submit(new SanitizeInput(password));  // password is defined in class InitialHandshake 
      pool.submit(new CustomHandshake(password));  // for e.g. clientthrows puzzlesIOException {
    return new pool.execute(new Handle(serverSocket.accept()));  // Handle connectionRequestHandler(0, poolSize);
  }

  public void } catch (IOException exhandleRequest() { 
    Future<?> future pool.shutdown= exec.submit(new Runnable(); {
    }	 
  }
}

In this noncompliant code example, the SanitizeInput task depends upon the CustomHandshake task for the value of password whereas the latter depends on the former to return a password that has been correctly sanitized.

Compliant Solution

This compliant solution recommends executing the interdependent tasks as a single task within the Executor. In other cases, where the subtasks do not require concurrency safeguards, the subtasks can be moved outside the threaded region that is required to be executed by the Executor.

class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocket;
  private final ExecutorService pool;

  public NetworkServer(int port, int poolSize) throws IOException {
    serverSocket = new ServerSocket(port @Override public void run() {
          try {
            helper.handle(server.accept());
    pool = Executors.newFixedThreadPool(poolSize);
  }
 
 } publiccatch void(IOException run(e) {
    try  {
      // ExecuteForward interdependentto subtaskshandler
 as a single combined task within this block
  }
    // Tasks SanitizeInput() and CustomHandshake()}
 are performed together in Handle(});
  }
  //  pool.execute(new Handle(serverSocket.accept())); // Handle connection
    } catch (IOException ex) { 
      pool.shutdown();
    }	 
  }
}

Always try to submit independent tasks to the Executor. Thread starvation issues can be mitigated by choosing a large pool size. Note that operations that have further constraints, such as the total number of database connections or total ResultSets open at a particular time, impose an upper bound on the thread pool size as each thread continues to block until the resource becomes available. The other rules of fair concurrency, such as not running time consuming tasks, also apply. When this is not possible, expecting to obtain real time result guarantees from the execution of tasks is conceivably, an unreasonable target.

Sometimes, a {{private static}} {{ThreadLocal}} variable is used per thread to maintain local state. When using thread pools, {{ThreadLocal}} variable should be used only if their lifetime is shorter than that of the corresponding task \[[Goetz 06|AA. Java References#Goetz 06]\]. Moreover, such variables should not be used as a communication mechanism between tasks. 

...

... Other methods such as shutting down the thread pool 
  // and task cancellation ...
}

According to the Java API documentation for the Executor interface [API 2014]:

[The interface Executor is] an object that executes submitted Runnable tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An Executor is normally used instead of explicitly creating threads.

The ExecutorService interface used in this compliant solution derives from the java.util.concurrent.Executor interface. The ExecutorService.submit() method allows callers to obtain a Future<V> object. This object both encapsulates the as-yet unknown result of an asynchronous computation and enables callers to perform additional functions such as task cancellation.

The choice of newFixedThreadPool is not always appropriate. Refer to the Java API documentation [API 2014] for guidance on choosing among the following methods to meet specific design requirements:

• newFixedThreadPool()
• newCachedThreadPool()
• newSingleThreadExecutor()
• newScheduledThreadPool()

Risk Assessment

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

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"

Sound automated detection is infeasible; heuristic checks could be useful.

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedCON20-J. Never apply a lock to methods making network calls      11. Concurrency (CON)      CON22-J. Do not use incorrect forms of the double-checked locking idiom