The events are proved to be unreliable. If a node doesn’t send a cache event due to a failure then it’s burden of an application to handle topology change events, checking for undelivered events, etc. This doesn’t sound like a straightforward solution to me.
Any other thoughts? Yakov, as one of main maintainers of the compute grid, please step in. — Denis > On Feb 3, 2017, at 5:38 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > 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 >>> >>
