Seems like a simple API for an external cron-like service to invoke an
action in Ignite would suffice, no? There are about a million of
scheduling services like that already, some have very good integration
into orchestrators of all sorts. Perhaps a trivial REST would do
instead of durable services, etc.?
Cos
--
Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.
On Mon, Jul 3, 2017 at 3:35 PM, Valentin Kulichenko
<valentin.kuliche...@gmail.com> wrote:
> Dmitry,
>
> Yes, this can be implemented using services in many cases, but:
>
> - It will require user to implement actual scheduling logic. It's quite a
> generic task, so I think it makes sense to have it directly on the API.
> - Most likely it will imply deploying separate service for each scheduled
> task. I don't think it's a very good idea.
> - Current services implementation is not durable. If cluster is restarted,
> all services are lost.
>
> -Val
>
> On Sat, Jul 1, 2017 at 12:34 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
>> 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?
>> > >
>> >
>>
