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 creation overhead in case of frequent or recurring requests, significant processing overhead, resource exhaustion pertaining to threads (leading to the {{OutOfMemoryError}}), thread scheduling and context switching overhead \[[Lea 00|AA. Java References#Lea 00]\].   

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 at once, causing the system 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. Thread pools overcome these issues by controlling Thread Pools overcome these disadvantages as the maximum number of worker threads that can be initiated and executed simultaneously, can be controlled. Every worker accepts a Runnable 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. Since 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 efficiently to the Channel, most of the thread creation overhead is 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 {
  protectedprivate final Helper hhelper = new Helper();
  private final StringServerSocket requestserver;

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

  public static //read the request data, else blockRequestHandler newInstance() throws IOException {
    return data; new RequestHandler(0); // Selects next available port
  }

  public void requesthandleRequest() {
    new Thread(new whileRunnable(true) {
      request  public =void acceptrun();
 {
          try {
        new Thread(new Runnable() {
    helper.handle(server.accept());
          public} voidcatch run(IOException e) {
            //  h.handle(request);Forward to handler
          }
        }
    }).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 a internal queue. The system will not get overwhelmed trying to respond to all incoming requests but will degrade gracefully by serving a fixed number of clients at a particular time. \[[Tutorials 08|AA. Java References#Tutorials 08]\]

According to \[[API 06|AA. Java References#API 06]\] the {{java.util.concurrent}} Interface {{Executor}}:

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.

The thread-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();
  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 newInstance(int poolSize) 
                                           throws IOException {
    return new RequestHandler(0, poolSize);
  }

  public void handleRequest

import java.util.concurrent.Executors;

class GetRequest {
  protected final Helper h = new Helper();
  String request;

  public synchronized String accept() {
    StringFuture<?> datafuture = "Read data from pipe";
 exec.submit(new Runnable() {
       //read the@Override requestpublic data, else blockvoid run() {
    return data;
  }

  public void request()try {
    int NoOfThreads = 200;
    Executor exec = (Executor) Executors.newFixedThreadPool(NoOfThreadshelper.handle(server.accept());
    while(true      } catch (IOException e) {
      request = accept();
    // Forward exec.Execute(new Runnable() {
to handler
         public void}
 run() {
      }
    h.handle(request});
  }
  // ... 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 may lead to to process an unbounded number of requests could result in severe performance degradation and exhaustion of system resources, deadlock, or system resource exhaustion and DOS.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

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]

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

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.TPS00.ISTART	Do not call the 'start()' method directly on Thread class instances

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedCON01-J. Avoid using ThreadGroup APIs      08. Concurrency (CON)      08. Concurrency (CON)