I would like to be able to create a Future task that calls a web service and when it returns, process the result, be it an Exception, SoapFault, or an actual value. But I would like to "send and forget"; in other words, I don't want the web app Controller from which I create the Future task to block waiting for the response.

I am using a ScheduledExecutorService and have tried with and without a CompletionService. I've tried the following:

Yes but at some point I need to get the result of the Future. So I have to call Future.get() somewhere.

I came up with a solution but I'm not sure how "best practice" it is.
Essentially I have a Singleton class that contains my ScheduledExecutorService and CompletionService. The Singleton class is instantiated and the ExecutorService and CompletionService are started when the app starts.

sygma6 wrote:
Yes but at some point I need to get the result of the Future. So I have to call Future.get() somewhere.

Either you know that the operation has completed, or you don't. If you know that it has completed, then you can just call get(), and it won't have any reason to block. If you don't know that it has completed, how will you decide when to get the result? Or, alternatively, what are you planning to do if, when you go to get the result, it's not ready yet?

Well, the idea is that I can have anywhere from 0->n Futures waiting to be processed at any time. So I call take() when a Future appears, and get() when it's done.

As it says in the JavaDoc:

Future<String> java.util.concurrent.CompletionService.take()
Retrieves and removes the Future representing the next completed task, waiting if none are yet present.

Again, I'm not sure if this is the best way to do this, that's why I'm putting the question out there. These Tasks are going to be calls on a network. They could take anywhere from 1-10 seconds. And as I said there will likely be a bunch waiting at the same time. I can't know when each one is going to be ready for processing. I don't care what order they are processed in. I just want them processed as they become available.

My thinking in doing it this way was:

1. to separate Task scheduling from Task processing, and

2. to put the burden of knowing when the Future has finished and has a result on the CompletionService.

I've seen many examples out there like this:
CompletionService<String> pool;

for (int i = 0; i < 1; i++) {
pool.submit(task);
}

for (int i = 0; i < 1; i++) {
pool.take().get();
}

But this mixes Task scheduling with Task processing. I will never know how many tasks there are at any given time, so I can't just do a simple loop. I need a Thread out there constantly polling to see if any Futures are ready and if so, process their result.

sygma6 wrote:
Well, the idea is that I can have anywhere from 0->n Futures waiting to be processed at any time. So I call take() when a Future appears, and get() when it's done.

But, again, how are you planning to know when it's done?

I can't know when each one is going to be ready for processing. I don't care what order they are processed in. I just want them processed as they become available.

So then you need to call take() or get() or whatever blocking call is appropriate. And if you don't want to block because there's other work you could be doing if nothing is available, then you should put that take() or get() call into a separate thread.

Well with the current setup it seems to be working just fine. In other words, I set up the ScheduledExecutorService and CompletionService when the app starts using a ServletContextListener. I also start a Thread that runs:

String result = completionService.take().get();

in an infinite loop. When there is nothing to take() it just waits. But if I submit a task it immediately calls get() as soon as that task is done.

I've also submitted tasks that take over a minute to finish (I just call Thread.sleep), and while they are sleeping I submit more tasks that start and finish immediately. So their take() calls are not blocked by the get() of the task that takes a minute to finish. And when the minute is up, its get() returns its result.

So it seems to be doing what I wanted - task submitting by the web app, task processing in a separate Thread. Based on what I am seeing I don't think I need to put the take() and the get() in different Threads, do I?

BUT I still have a problem I hadn't realized. Currently I am doing a completionService.submit(task) in my schedule() method. Which allows me to call completionService.take().get() in my separate Thread. But that was just for testing! What I really need to do in the schedule() method is scheduledExecutorService.schedule(task, 0, TimeUnit.SECONDS). Because some tasks are executed immediately, other run every hour, etc.

So how do I get the tasks from the scheduledExecutorService as they become available in my separate thread? The call to completionService.take().get() is no longer firing, because I am no longer submitting tasks to completionService. So it seems I need to use the completionService in order to process the tasks as they become available. But how can I schedule tasks using the completionService?

... it's with good reason that they say concurrency is a tough topic, in Java and in general ...