weld + gf v3 + asynchronous task execution
Hello,
I have a gh v3 with default weld (v 1.0.0). And the situation is following:
I have ITask interface:
public interface ITask<T,R> {
Future<R> execute(T value);
}Implementation:
@Stateless
public class SimpleTask implements ITask<Integer, Integer> {
@Override
@Asynchronous
public Future<Integer> execute(Integer value) {
System.err.println("started ..." + value);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
System.err.println("completed ..." + value);
return new AsyncResult<Integer>(value * 2);
}
}And a bean that invokes tasks:
@Startup
@Singleton
public class InitBean {
@Inject
ITask task;
@PostConstruct
public void init() {
System.err.println("!!!!!!!!!!! starting up ......");
List<Future<Integer>> tasks = new ArrayList<Future<Integer>>();
for (int i =0; i < 5; i++) {
tasks.add(task.execute(new Integer(i)));
}
}
}The expected result is asynchronous task execution (i.e output: started ... 1, started ... 2 ..., completed 1, completed 2...), but the actual result is synchronous (started ... 1, completed 1, started ... 2, completed 2, etc). Trying to check if future is done whether cancelled I'm getting: IllegalStateException: Object does not represent actual Future.
Removing the interface from SimpleTask and using it directly, i.e:
@Stateless
public class SimpleTask {
@Asynchronous
public Future<Integer> execute(Integer value) {
System.err.println("started ..." + value);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
System.err.println("completed ..." + value);
return new AsyncResult<Integer>(value * 2);
}
}works as expected to be working (i.e. asynchronously). Is it a bug? Or ejb feature? If it is not a bug, how can I overcome such limitation? I want to make some kind of pooled task executor (input is ITask instance with asynchronous invocation, List of objects to be executed by ITask and pool size). Relying on gf pooling is not sufficient (64 threads may be too much, I want to limit, for example, with 5 tasks at a time).
Any help is appreciated.
Thanks,
Vadim
