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 consuming, I/O bound, session based or isolated tasks.
| Wiki Markup |
|---|
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]\]. |
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 and stores it in a temporary Channel like a buffer or a queue until resources become available. Since threads are reused and can be added efficiently to the Channel, most of the thread creation overhead is eliminated.
Noncompliant Code Example
This noncompliant code example demonstrates the Thread-Per-Message design that fails to provide graceful degradation of service.
| Code Block | ||
|---|---|---|
| ||
class Helper {
public void handle(String request) {
//...
}
}
class GetRequest {
protected final Helper h = new Helper();
String request;
public synchronized String accept() {
String data = "Read data from pipe";
//read the request data, else block
return data;
}
public void request() {
while(true) {
request = accept();
new Thread(new Runnable() {
public void run() {
h.handle(request);
}
}).start();
}
}
}
|
Compliant Solution
| Wiki Markup |
|---|
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]\] |
| Wiki Markup |
|---|
According to \[[API 06|AA. Java References#API 06]\] the {{java.util.concurrent}} Interface {{Executor}}: |
Wiki Markup
| Code Block | ||
|---|---|---|
| ||
import java.util.concurrent.Executors;
class GetRequest {
protected final Helper h = new Helper();
String request;
public synchronized String accept() {
String data = "Read data from pipe";
//read the request data, else block
return data;
}
public void request() {
int NoOfThreads = 200;
Executor exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
while(true) {
request = accept();
exec.Execute(new Runnable() {
public void run() {
h.handle(request);
}
});
}
}
}
|
Risk Assessment
Using simplistic concurrency primitives may lead to severe performance degradation and exhaustion of system resources.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON02-J | low | probable | low | P6 | L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[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] |
CON01-J. Avoid using ThreadGroup APIs 08. Concurrency (CON) 08. Concurrency (CON)