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 - 26 Oct 2006 12:18 GMT
> 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