Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id BFB78200CC6 for ; Tue, 4 Jul 2017 00:39:48 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id BE8D5160BF9; Mon, 3 Jul 2017 22:39:48 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 10802160BEC for ; Tue, 4 Jul 2017 00:39:47 +0200 (CEST) Received: (qmail 13082 invoked by uid 500); 3 Jul 2017 22:39:47 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 13070 invoked by uid 99); 3 Jul 2017 22:39:47 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jul 2017 22:39:47 +0000 Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id EDB6C1A00A2 for ; Mon, 3 Jul 2017 22:39:46 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id v202so93336758itb.0 for ; Mon, 03 Jul 2017 15:39:46 -0700 (PDT) X-Gm-Message-State: AKS2vOwfzlLv5HcLv8hkcM/1XwtXHgAzYSmRY3A28gxKOzaZTAoEcJQo bVCAX1jj2SdA6j1+P+xGOQGxUdIn1mg+ X-Received: by 10.36.33.202 with SMTP id e193mr32730481ita.92.1499121586347; Mon, 03 Jul 2017 15:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.56.3 with HTTP; Mon, 3 Jul 2017 15:39:05 -0700 (PDT) In-Reply-To: References: From: Dmitriy Setrakyan Date: Mon, 3 Jul 2017 15:39:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Distributed scheduling To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="001a1146ee3ea15359055371712d" archived-at: Mon, 03 Jul 2017 22:39:48 -0000 --001a1146ee3ea15359055371712d Content-Type: text/plain; charset="UTF-8" Hm... I think we should definitely make our services durable. Everything in Ignite should be durable now. As far as scheduling, makes sense as well. Let's make it durable too. D. On Mon, Jul 3, 2017 at 3:35 PM, Valentin Kulichenko < valentin.kulichenko@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 > 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.kulichenko@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 < > > dsetrakyan@apache.org> > > > wrote: > > > > > > > On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov < > > > akuznetsov@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? > > > > > > > > > > --001a1146ee3ea15359055371712d--