I think this definitely should be part of Compute Grid API. We can then implement ScheduledExecutorService based on this API (similar to existing ExecutorService implementation which is based on existing compute API), but it should be a separate task.
-Val On Fri, Feb 3, 2017 at 3:42 PM, Denis Magda <dma...@apache.org> wrote: > Igniters, > > Conjure the cases when a task (aka. distributed computation): > - has to executed in an hour or > - its execution has to be triggered only the other task completes. > > The first time-based case is partially supported by Ignite’s executor > service. However, it has a significant flaw - a task scheduling happens > locally on a node and if the node goes down the task will never be executed. > > The second case is not supported at all but will be nice to have. > > The question is how would you implement this API? I see at least three > options here: > Extend Compute Grid API by adding ‘scheduleTask(…)’ and > ‘executeTasks(tasksChain)’ like methods. This is my preferred component > because it has all the interfaces needed to implement computations, it > supports runnables/callables, it’s empowered with the peer-class-loading > feature. > Service Grid API might be a candidate for this but then ‘task’ will be > equal to ‘service’ and we can’t take advantage of the peer-class-loading. > Extend Ignite’s executor service making existing scheduling methods > independent of the local node and add a method like > 'executeTasks(tasksChain)’ for tasks chaining. However, this component > supports simple runnables/callables and doesn’t have fine-grained interface > like ComputeTask/ComputeJob that add more flexibility for complex scenarios. > > My preference is to design the API basing on compute grid. What’s your > thoughts on this? Bring the up! > > — > Denis >
