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? > > >