Why can't we use a cache event, e.g. storing some flag in cache at the end of task 1 to notify that task 2 needs to be started?
We cannot create an API for absolutely every possible task event. I can come up with many other possible permutations for task sequencing, e.g. task 2 starts in the middle of task 1. I think that the proper way here is to use other system events on the user side to possibly trigger some task execution here. D. On Sat, Feb 4, 2017 at 3:04 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > 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 > > >
