Long-running tasks should provide a mechanism for notifying the application upon abnormal termination. Failure to do so does not cannot cause any resource leaks because the threads in the pool are still recycled, but it makes failure diagnosis extremely difficult.
...
| Code Block | ||
|---|---|---|
| ||
final class PoolService {
private final ExecutorService pool = Executors.newFixedThreadPool(10);
public void doSomething() {
pool.execute(new Task());
}
}
final class Task implements Runnable {
@Override public void run() {
// ...
throw new NullPointerException();
// ...
}
}
|
The task does not fails to notify the application when it terminates unexpectedly as a result of the runtime exception. Moreover, it does not use any lacks a recovery mechanism. Consequently, if Task throws were to throw a NullPointerException, the exception is would be ignored.
Compliant Solution (ThreadPoolExecutor Hooks)
| Wiki Markup |
|---|
Task-specific recovery or clean-up actions can be performed by overriding the {{afterExecute()}} hook of the {{java.util.concurrent.ThreadPoolExecutor}} class. This hook is called either when a task concludes successfully by executing all statements in its {{run()}} method or when the task halts because of an exception. (Some implementations may fail to catch {{java.lang.Error}} might not be captured on specific implementations. See [Bug ID 6450211|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6450211] for more information \[[SDN 2008|AA. Bibliography#SDN 08]\]). When using this approach, substitute the executor service with a custom {{ThreadPoolExecutor}} that overrides the {{afterExecute()}} hook as shown below: |
...
| Wiki Markup |
|---|
The {{ExecutorService.submit()}} method can be used to submit a task to a thread pool instead (in place of the {{execute()}} method) to submit a task to a thread pool and obtain a {{Future}} object. NoteWhen that the uncaught exception handlertask is notsubmitted calledvia if {{ExecutorService.submit()}} is invoked. This is, thrown exceptions will never reach the uncaught exception handler, because the thrown exception is considered to be part of the return status and is consequently wrapped in an {{ExecutionException}} and re-thrown by {{Future.get()}} \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
...
TPS03-EX1: This rule may be violated if when, and only when, the code for all runnable and callable tasks has been audited to ensure that no exceptional conditions are possibleimpossible. Nonetheless, it is usually a remains good practice to install a task-specific or global exception handler to initiate recovery or log the exceptional condition.
Risk Assessment
Failing Failure to provide a mechanism for reporting that tasks in a thread pool failed as a result of an exceptional condition can make it harder to find the source of the issue.
...
| Tasklist | ||||
|---|---|---|---|---|
| ||||
||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name|| |
Automated Detection
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5f911bcb2274b273-21964dc2-48a84f57-a73fa8f4-5dfedd2e4bfc66afac2831f3"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | interfaces | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="50ca36f6723c35c3-f7b96cd8-44ed47f0-b752b732-1f3879d0e1e9a2b2c4b6a7b4"><ac:plain-text-body><![CDATA[ | [[Goetz 2006 | AA. Bibliography#Goetz 06]] | Chapter 7.3: Handling abnormal thread termination | ]]></ac:plain-text-body></ac:structured-macro> |
...