Associating additional data with Future object

[Maciej]

Hi,

I've utilized Consumer/Producer pattern together with CompletionService
from java.util.concurrent package.

Delegator class delegates (in its thread) tasks to producers by use of
CompletionService:

CompletionService cs = ....
while(true) {
Task task = receive();
Future<Result> f = cs.submit(task);
}


Consumer class (in its thread) uses CompletionService to handle with
results of task execution

while(true) {
Futute<Result> f = cs.take();
handle(f);
}



But it also needs to know some details connected with the executed
Task. These details cannot be given in the Result object of /taken/
Future<Result> task, since sometimes task execution could cause
exception and then the associated Result object is /null/.

What I tried to do was to use shared Map object, in which Future
objects get associated with their tasks by Delegator:

Future<Result> f = cs.submit(task);
tasks.put(f, task)

but in between Consumer may take Future object which has no task
assiociated in tasks map.

Any solution to that ? Is there anything like BlockingHashMap ?

Regards,
Maciej

 

[Chris Uppal]

But it also needs to know some details connected with the executed
Task. These details cannot be given in the Result object of /taken/
Future<Result> task, since sometimes task execution could cause
exception and then the associated Result object is /null/.

One way you could do this would be to take a look at the (very simple) source
for ExecutorCompletionService, and create a custom subclass or peer class which
extends submit() to take extra data which it then stores in its own custom
implementation of Future<> (replacing the use of the private internal class
ExecutorCompletionService.QueuingFuture). Your consumer code would then cast
the Future<> to MyExtendedFutureTask<> (or whatever you'd called it) and so
would be able to ask it for the associated data.

Its a little unfortunate that the existing framework isn't factored to make it
easier to plug in a replacement Future factory, nor to ask for the
Callable/Runnable which forms the underlying task, but I suppose not even Doug
Lea can think of everything...

-- chris