Queries on Java Future and RejectionHandler

Question

I had some queries regarding Future usage. Please go through below example before addressing my queries.

http://javarevisited.blogspot.in/2015/01/how-to-use-future-and-futuretask-in-Java.html

1. The main purpose of using thread pools & Executors is to execute task asynchronously without blocking main thread. But once you use Future, it is blocking calling thread. Do we have to create separate new thread/thread pool to analyse the results of Callable tasks? OR is there any other good solution?
2. Since Future call is blocking the caller, is it worth to use this feature? If I want to analyse the result of a task, I can have synchronous call and check the result of the call without Future.
3. What is the best way to handle Rejected tasks with usage of RejectionHandler? If a task is rejected, is it good practice to submit the task to another Thread or ThreadPool Or submit the same task to current ThreadPoolExecutor again?

Please correct me if my thought process is wrong about this feature.

Answer 1

Your question is about performing an action when an asynchronous action has been done. Futures on the other hand are good if you have an unrelated activity which you can perform while the asynchronous action is running. Then you may regularly poll the action represented by the Future via isDone() and do something else if not or call the blocking get() if you have no more unrelated work for your current thread.

If you want to schedule an on-completion action without blocking the current thread, you may instead use CompletableFuture which offers such functionality.

Answer 2

CompletableFuture is the solution for queries 1 and 2 as suggested by @Holger

I want to update about RejectedExecutionHandler mechanism regarding query 3.

Java provides four types of Rejection Handler policies as per javadocs.

1. In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime RejectedExecutionException upon rejection.

2. In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism that will slow down the rate that new tasks are submitted.

3. In ThreadPoolExecutor.DiscardPolicy, a task that cannot be executed is simply dropped.

4. In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down, the task at the head of the work queue is dropped, and then execution is retried (which can fail again, causing this to be repeated.)

CallerRunsPolicy: If you have more tasks in task queue, using this policy will degrade the performance. You have to be careful since reject tasks will be executed by main thread itself. If Running the rejected task is critical for your application and you have limited task queue, you can use this policy.

DiscardPolicy: If discarding a non-critical event does not bother you, then you can use this policy.

DiscardOldestPolicy: Discard the oldest job and try to resume the last one

If none of them suits your need, you can implement your own RejectionHandler.