Val,
In this case, we should have a notion of a named scheduler and ensure that
we don't schedule the same task more than once. This is beginning to look
more like a durable cluster singleton service, no?
D.
On Fri, Jun 30, 2017 at 1:39 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> I think this functionality should provide durable way of scheduled task or
> closure execution on the cluster. Job descriptors should be persisted on
> server side and executed there.
>
> As for API, I believe this should be part of Compute Grid. I suggest to
> introduce IgniteCompute#withSchedulingPolicy(SchedulingPolicy policy)
> method, where SchedulingPolicy is smth like this:
>
> public interface SchedulingPolicy {
> /**
> * @return Timestamp of next execution.
> */
> public Date nextTime();
> }
>
> This will enable scheduling for all compute features (tasks, callables,
> closures, etc.) and also very flexible. Policy implementation can provide
> simple periodic scheduling, scheduling based on Cron or anything else.
>
> Thoughts?
>
> -Val
>
> On Fri, Jun 30, 2017 at 7:55 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
> > On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov <
> akuznet...@apache.org>
> > wrote:
> >
> > > Dmitriy,
> > >
> > > >> Can you provide a simple example of API calls that will make this
> > > possible?
> > > API could be like this:
> > > 1) via scheduler:
> > > Ignite ignite = Ignition.start(....);
> > >
> > > ignite.scheduler().schedulel(job, "0 0 * * *"); // This will execute
> job
> > > every day at 00:00
> > >
> > > 2) via compute
> > >
> > > Ignite ignite = Ignition.start(....);
> > >
> > > ignite.compute().schedulel(task, "0 0 * * *"); // This will execute
> > > compute
> > > task every day at 00:00
> > >
> > > Make sense?
> > >
> > >
> > Yes, it does, but I am failing to see how is this a *distributed*
> > scheduling. Are we persisting the scheduler somewhere in the cluster or
> is
> > it only triggered on the client side?
> >
>
