Tasks Scheduling and Chaining

[dmagda]

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
 

[Valentin Kulichenko]

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 <[hidden email]> 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
>

[dsetrakyan]

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 <
[hidden email]> 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 <[hidden email]> 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
> >
>

[dmagda]

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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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
>>>
>>

[luqmanahmad]

Hi all,

I personally think this is a good candidate for implementing Ignite Queue Based messaging where any one of the given nodes can pick up the message. Upon task completion it should fire an event which should be picked up by any node just the way jms queue works. However I am not sure whether we could achieve the same functionality with topic based messaging or not, but then I can think of cases where it will not work and needs to be handled by clients

I also agree with what Val said as well which is definitely something missing from the computation API. [+1]

Other solution would be is to implement some kind of event bus at the cache level which is able to register user related events in a specific order and function definitions can be implemented respectively on the listener side. Upon the completion of a task user should fire an event on that event bus - the only difference between this and ignite topic based messaging would be that upon firing the event it will select a random node on which the message will be deliver, which guarantees that the message is delivered one and only once to one random node. I know we have already got so many ignite events but 1. they are not reliable 2. we already so many events going inside the ignite, so would drop it.

- Luqman