Develop Reference

ExecutorService for Do-While Loop in Java

I am new to concurrency and I was trying to implement executor service concurrency for a do-while loop. But I always run into RejectedExecutionException
Here is my sample code:
do {
Future<Void> future = executor.submit(new Callable<Void>() {
#Override
public Void call() throws Exception {
// action
return null;
}
});
futures.add(future);
executor.shutdown();
for (Future<Void> future : futures) {
try {
future.get();
}
catch (InterruptedException e) {
throw new IOException(e)
}
}
}
while (true);
But this seems incorrect. I think I am calling the shutdown at the wrong place. Can anyone please help me implement Executor Service in a do-while loop correctly. Thanks.

ExecutorService.shutdown() stops the ExecutorService from accepting anymore jobs. It should be called when you're done submitting jobs.
Also Future.get() is a blocking method, which means it will block the execution of current thread and next iteration of loop will not continue unless this future (on which the get is called) returns. This will happen in every iteration, which makes the code non parallel.
You can use a CountDownLatch to wait for all the jobs to return.
Following is the correct code.
final List<Object> results = Collections.synchronizedList(new ArrayList<Object>());
final CountDownLatch latch = new CountDownLatch(10);//suppose you'll have 10 futures
do {
Future<Void> future = executor.submit(new Callable<Void>() {
#Override
public Void call() throws Exception {
// action
latch.countDown();//decrease the latch count
results.add(result); // some result
return null;
}
});
futures.add(future);
} while (true);
executor.shutdown();
latch.await(); //This will block till latch.countDown() has been called 10 times.
//Now results has all the outputs, do what you want with them.
Also if you're working with Java 8 then you can take a look at this answer https://stackoverflow.com/a/36261808/5343269

You're right, the shutdown method is not being called at the correct time. The ExecutorService will not accept tasks after shutdown is called (unless you implement your own version that does).
You should call shutdown after you've already submitted all tasks to the executor, so in this case, somewhere after the do-while loop.

From ThreadPoolExecutor documentation:
Rejected tasks
New tasks submitted in method execute(Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated.
In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor) method of its RejectedExecutionHandler
From your code, it's clearly evident that you are calling shutdown() first and submitting the tasks later.
On a different note, refer to this related SE question for right way of shutting down ExecutorService:
ExecutorService's shutdown() doesn't wait until all threads will be finished

Handling the Hanging Tasks [duplicate]

This question already has answers here:
ExecutorService that interrupts tasks after a timeout
(11 answers)
Closed 7 years ago.
This is just an example to explain my problem...
I am using ExecutorService with 20 active threads and 75K max queued items...
In my case, a normal task should not take more than 10 seconds, if it takes more time that means there's some problem with the task.
If all the threads are hung due to problematic tasks my RejectionHandler would restart the entire service.
I have two questions here:
I do not like the idea of restarting the service, instead if there's
way to detect hanging thread and we could just restart that hung
thread that would be great. I have gone through couple of articles to handle hung threads with ThreadManager but have not found anything
with ExecutorService.
I am very much fascinated about the Executors.newCachedThredPool()
because on peak days we are heavily loaded with incoming tasks, and
on other days they are very few. Any suggestions would be greatly
appreciated.
public class HangingThreadTest {
// ExecutorService executorService = Executors.newCachedThreadPool()
private static ExecutorService executorService = new ThreadPoolExecutor(10,
20, 5L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(75000));
public static void main(String... arg0) {
for (int i = 0; i < 50000; i++) {
executorService.submit(new Task());
}
}
}
/**
* Task to be completed
*/
class Task implements Runnable {
private static int count = 0;
#Override
public void run() {
count++;
if (count%5 == 0) {
try {
System.out.println("Hanging Thread task that needs to be reprocessed: "
+ Thread.currentThread().getName()+" count: "+count);
Thread.sleep(11000);
} catch (InterruptedException e) {
// Do something
}
}
else{
System.out.println("Normal Thread: "
+ Thread.currentThread().getName()+" count: "+count);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
//Do something
}
}
}
}

There is no build-in mechanism in Executors framework that would help terminate a thread if it has been running for more than a threshold value.
But we can achieve this with some extra code as below:
Get the Future object returned by the executorService.submit(...);.
Future future = executorService.submit(new Task());
Call the get method on this future object to and make it wait only for threshold interval for task completion. Below, an example that is waits for only 2 secs.
try {
f.get(2, TimeUnit.SECONDS);
} catch (TimeoutException e) {
f.cancel(true);
} catch (Exception e) {}
The above code waits for 2 seconds for task completion it throws a TimeoutException if it doesn't get completed during that time. Subsequently we can call cancel method on the future object. This results in setting the interrupt flag in the thread that is executing the task.
Now the final change is, in the Task class code we need to check at necessary points (application dependent), whether the interrupt flag has been set to true using isInterrupted() method of Thread class. If interrupted==true, we can do the necessary clean up and return from the run method immediately. The critical piece here is to identify the necessary points in your Task class where you want to check for this interrupted flag.
This makes the thread available for processing next task.

You may have a look at this article, it was very helpful for me before when I was facing the same problem : Java Hanging Thread Detection

Java: Get Method on a Future from scheduleAtFixedRate

Consider the following code:
public static void main(String ... args) throws InterruptedException {
ScheduledExecutorService threadsPool = Executors.newSingleThreadScheduledExecutor();
Future<?> f = threadsPool.scheduleAtFixedRate(() -> {
try {
Thread.sleep(1);
} catch (Exception e) {
e.printStackTrace();
}
}, 0, 2, TimeUnit.SECONDS);
Thread.sleep(5000);
threadsPool.shutdown();
System.out.println(threadsPool.awaitTermination(1, TimeUnit.SECONDS));
try {
f.get();
} catch (Exception e) {
e.printStackTrace();
}
}
Note the sleeping time of the evil thread: 1ms. This guarantees that the shutdown will be while the threads pool is waiting for the next iteration and the evil thread is not running.
This results in a a CancellationException on the get() method: If I understand correctly, ScheduledExecutorService cancels any pending task when calling shutdown(), so this behavior makes sense.
Next I have changed the sleeping time of evil thread from 1 to 1999. This guarantees that the shutdown will be during the sleeping of the evil thread.
This results in waiting forever on the get() method.
My next question is why is this behavior happening? Calling shutdown will gracefully shutdown the service. Indeed, the evil thread finishes the iteration and doesn't start again.
But why doesn't the get() method return? Am I misunderstanding the get() method on ScheduledFuture?
I thought that as soon as the evil thread finishes, and the pool is shutdown, the get() method should return null.

If the future did not complete then it is possible that the future.cancel() method was invoked by the shutdown method (or the executor somehow cancelled the future).
This is the expected behavior of requesting the executor to shutdown, since it does not wait for tasks to complete.
If the future has been cancelled before finishing, throwing the CancellationException is the expected behavior. Otherwise it would wait for ether for the task to return.
In this case, since you use ScheduledExecutorService you can use the ScheduledFuture instead of Future in this case to get more information. https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledFuture.html
This will allow you to access the getDelay method provided by the Delayed interface.
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Delayed.html
If you also check the source code of the method scheduleAtFixedRate you will see that it actually creates a ScheduledFutureTask. See code below. (Copy from source.)
/**
* #throws RejectedExecutionException {#inheritDoc}
* #throws NullPointerException {#inheritDoc}
* #throws IllegalArgumentException {#inheritDoc}
*/
public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
long initialDelay,
long period,
TimeUnit unit) {
if (command == null || unit == null)
throw new NullPointerException();
if (period <= 0)
throw new IllegalArgumentException();
ScheduledFutureTask<Void> sft =
new ScheduledFutureTask<Void>(command,
null,
triggerTime(initialDelay, unit),
unit.toNanos(period));
RunnableScheduledFuture<Void> t = decorateTask(command, sft);
sft.outerTask = t;
delayedExecute(t);
return t;
}
The ScheduledFutureTask's run method automatically reexecutes it as soon as it is finished. (see last line of source code).
/**
* Overrides FutureTask version so as to reset/requeue if periodic.
*/
public void run() {
boolean periodic = isPeriodic();
if (!canRunInCurrentRunState(periodic))
cancel(false);
else if (!periodic)
ScheduledFutureTask.super.run();
else if (ScheduledFutureTask.super.runAndReset()) {
setNextRunTime();
reExecutePeriodic(outerTask);
}
}
The outerTask is this so it is actually the ScheduledFutureTask itself. So it is never complete. For this reason you can never actually get the result.

Not calling get on list of futures

I'm using a global Executor service with some fixed thread pool size. We have bunch of related tasks that we submit for execution and wait on list of futures.
Recently, we faced a high CPU utilization issue and on debugging I found that an exception occurred while calling get() on one of the item in list of futures. Current, we iterate over the list and there is a try catch surrounding the whole loop.
try{
List<Result> results = new ArrayList<>()
for(Future<Result> futureResult: futureResults{
Result result = futureResult.get();
results.add(result);
}
} catch(Exception e){
throw new InternalServiceException(e);
}
//Do something with results
Wanted to know the behaviour of other threads if get is never called on some of the items in future. I tried searching but was not able to find anything.
Also, can this behaviour trigger high CPU utilization ?

http://www.journaldev.com/1650/java-futuretask-example-program
I would still check if the future isDone as in the example above.
If you need to run other operations or want to utilize the CPU better then I would put the collector in a separate thread and perhaps just poll for results every minute or so.
Could be scheduled or handled by Thread.sleep.

Executors class provides various methods to execute Callable in a thread pool. Since callable tasks run in parallel, we have to wait for the returned Object.
Callable tasks return java.util.concurrent.Future object. Using Future we can find out the status of the Callable task and get the returned Object.
It provides get() method that can wait for the Callable to finish and then return the result.
There is an overloaded version of get() method where we can specify the time to wait for the result, it’s useful to avoid current thread getting blocked for longer time.
Future provides cancel() method to cancel the associated Callable task. There are isDone() and isCancelled() methods to find out the current status of associated Callable task.
Here is a simple example of Callable task that returns the name of thread executing the task after some random time.
We are using Executor framework to execute 10 tasks in parallel and use Future to get the result of the submitted tasks.
public class FutureObjectTest implements Callable<String>{
#Override
public String call() throws Exception {
long waitTime = (long) (Math.random()*10000);
System.out.println(Thread.currentThread().getName() + " waiting time in MILISECONDS " + waitTime);
Thread.sleep(waitTime);
return Thread.currentThread().getName() + " exiting call method.";
}
public static void main(String [] args){
List<Future<String>> futureObjectList = new ArrayList<Future<String>>();
ExecutorService executorService = Executors.newFixedThreadPool(5);
Callable<String> futureObjectTest = new FutureObjectTest();
for(int i=0; i<10; i++){
Future<String> futureResult = executorService.submit(futureObjectTest);
futureObjectList.add(futureResult);
}
for(Future<String> futureObj : futureObjectList){
try {
System.out.println(futureObj.get());
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace();
}
}
System.out.println("Starting get method of wait");
////////////get(Timeout) method///////
futureObjectList.clear();
for(int i=0; i<10; i++){
Future<String> futureResult = executorService.submit(futureObjectTest);
futureObjectList.add(futureResult);
}
executorService.shutdown();
for(Future<String> futureObj : futureObjectList){
try {
System.out.println(futureObj.get(2000,TimeUnit.MILLISECONDS));
} catch (InterruptedException | ExecutionException | TimeoutException e) {
e.printStackTrace();
}
}
}
}

Java EE WebListener and Thread

I've a servlet tagged as #WebListener.
public void contextInitialized(ServletContextEvent event) {
schedulerEngine = Executors.newSingleThreadScheduledExecutor();
schedulerEngine.scheduleAtFixedRate(new Batch1(), 0, MILLISECONDS_ITERATE_PA, TimeUnit.MILLISECONDS);
schedulerEngine.scheduleAtFixedRate(new Batch2(), 0, MILLISECONDS_ITERATE_IAS, TimeUnit.MILLISECONDS);
schedulerEngine.scheduleAtFixedRate(new Batch3(), 0, MILLISECONDS_ITERATE_EV1, TimeUnit.MILLISECONDS);
schedulerEngine.scheduleAtFixedRate(new Batch4(), 0, MILLISECONDS_ITERATE_MV1, TimeUnit.MILLISECONDS);
schedulerEngine.scheduleAtFixedRate(new Batch5(), 0, MILLISECONDS_ITERATE_BB, TimeUnit.MILLISECONDS);
schedulerEngine.scheduleAtFixedRate(new Batch6(), 0, MILLISECONDS_ITERATE_EV, TimeUnit.MILLISECONDS);
}
public class BatchX implements Runnable {
#Override
public void run() {
....
}
}
The MILLISECONDS_ITERATE_XX = 60000 (1 minute).
Is it possible that some thread stop itself for memory problems?
If in my BatchX() run method I have an exception (for example NullPointerException), the thread stop forever?

It is always possible for a block of code to be interrupted by an exception. Whether this is fatal or not depends on what measures you take to prevent or recover from them:
For checked exceptions e.g. IOException, you will need to put some recovery and/or logging code in your catch block and then decide if you wish to exit the method or continue executing.
In the case of unchecked exceptions e.g. NullPointerException it's best to prevent them, not catch them, for example by making sure that no object can be null when you try to access it, or that no index may exceed the bounds of an array when iterating, etc.
Edit: To answer your particular question, the Javadoc says:
If any execution of the task encounters an exception, subsequent
executions are suppressed. Otherwise, the task will only terminate via
cancellation or termination of the executor.