Here is the scenario we cannot support for now. User cannot cancel tasks
after master node is restarted. Of course, we need to restore
IgniteCompute.cancelTask(sesId) first.
I am against changing closures execution mechanics. I would better
simplify and optimize task execution. This way, both tas
The fact that closure create task is internal implementation detail which
may (and should for performance reasons) change in future. Please provide
the use case where use needs anything except for the future itself.
On Tue, May 30, 2017 at 2:35 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.c
+1 to Yakov. Closure execution also creates a task and I don't see any
reason for hiding it. And actually we don't hide it - we fire task/job
events, apply the same failover mechanisms, etc.
What probably is confusing here is the name of the class. ComputeTaskFuture
indeed looks like applied only
Vladimir,
I disagree. I understand this is minor issue, but still.
Here are the points:
1. TaskSession is supported for all compute methods. Please see -
ComputeFailoverExample. Every compute method starts a task.
2. You still return task future, but method return type is a
super-interface.
3. U
Valya,
This future contains task session. We intentionally changed return type to
plain IgniteFuture for closure methods, as there is no notion of "session"
and "task" for them. ComputeTaskFuture now returned only from task-related
methods ("execute"). Unless I am missing something, this approach
Folks,
I noticed that the new async API for IgniteCompute returns IgniteFuture,
while previously we used to have its extension - ComputeTaskFuture, which
contains useful information about the executed task session.
Should this be fixed?
-Val
