Return-Path: 
 <dev-return-487-apmail-zest-dev-archive=zest.apache.org@zest.apache.org>
X-Original-To: apmail-zest-dev-archive@minotaur.apache.org
Delivered-To: apmail-zest-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 1497318625
	for <apmail-zest-dev-archive@minotaur.apache.org>;
 Thu, 25 Jun 2015 08:29:54 +0000 (UTC)
Received: (qmail 73550 invoked by uid 500); 25 Jun 2015 08:29:54 -0000
Delivered-To: apmail-zest-dev-archive@zest.apache.org
Received: (qmail 73513 invoked by uid 500); 25 Jun 2015 08:29:54 -0000
Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@zest.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@zest.apache.org>
List-Post: <mailto:dev@zest.apache.org>
List-Id: <dev.zest.apache.org>
Reply-To: dev@zest.apache.org
Delivered-To: mailing list dev@zest.apache.org
Received: (qmail 73500 invoked by uid 99); 25 Jun 2015 08:29:53 -0000
Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jun 2015 08:29:53 +0000
Received: from localhost (localhost [127.0.0.1])
	by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org)
 with ESMTP id 3B6D9C095D
	for <dev@zest.apache.org>; Thu, 25 Jun 2015 08:29:53 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: 1.893
X-Spam-Level: *
X-Spam-Status: No, score=1.893 tagged_above=-999 required=6.31
	tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=3,
	RCVD_IN_MSPIKE_H2=-1.108, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
	autolearn=disabled
Authentication-Results: spamd4-us-west.apache.org (amavisd-new);
	dkim=pass (2048-bit key) header.d=gmail.com
Received: from mx1-us-east.apache.org ([10.40.0.8])
	by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new,
 port 10024)
	with ESMTP id 3V7ibF5f1XCb for <dev@zest.apache.org>;
	Thu, 25 Jun 2015 08:29:46 +0000 (UTC)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com
 [209.85.223.169])
	by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with
 ESMTPS id 8B7BF47BCC
	for <dev@zest.apache.org>; Thu, 25 Jun 2015 08:29:46 +0000 (UTC)
Received: by ieqy10 with SMTP id y10so49979892ieq.0
        for <dev@zest.apache.org>; Thu, 25 Jun 2015 01:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:from:date:message-id
         :subject:to:content-type;
        bh=C/PPmjJByPRUDagR7BhhmPTUf9r2C4y6tgPkFf9XTfA=;
        b=CqKBqZW7aJrJdh2E8G3RDq16a0bnmosu5VdYsRCEAuebrSUay4jqUetJ8fHA2KYvWJ
         +1eiLONwmKMVGPJ8JFz+bzLjpRQD4yy9lu2AeSi8TeBVHNXHzmbuPcfHQuw06B1nGeI8
         EdilcEn9AHfQONzP59eu0kHJKCcNNZIzRlm/eTxQTXdqKeYm/z0q8qgxADmkrDGy3DcK
         wbEjNcMw91KcMOQaj1yL05/8wvW/+ySOoI8w+bWhsgTdw9SjBFZGkvWs88mlQtyjmJp0
         3qVHmh2QUEvRY2xjJjI6H5alm+IqezLH+wQM0ZRykMB39oJdbwGgP/8WbOkZpNv/FYSi
         8yOw==
X-Received: by 10.107.4.6 with SMTP id 6mr2464451ioe.49.1435220980255; Thu, 25
 Jun 2015 01:29:40 -0700 (PDT)
MIME-Version: 1.0
Sender: hedhman@gmail.com
Received: by 10.36.98.18 with HTTP; Thu, 25 Jun 2015 01:29:20 -0700 (PDT)
In-Reply-To: 
 <CADmm+KdGCHAQ_Eey+Lox63hqvVeQ31xS5CVRHmaufDSisNffLg@mail.gmail.com>
References: 
 <CADmm+KdGCHAQ_Eey+Lox63hqvVeQ31xS5CVRHmaufDSisNffLg@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Thu, 25 Jun 2015 16:29:20 +0800
X-Google-Sender-Auth: 1Do_TLGCxb2JPqc_w6ns07tKfHE
Message-ID: 
 <CADmm+KezHgFCpJvmQT3NSc-UZRpDexCTgRGO-EduRWu=xE93Tg@mail.gmail.com>
Subject: Re: Scheduler Library upgrade?
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a113ef45ab3f7550519536c38

--001a113ef45ab3f7550519536c38
Content-Type: text/plain; charset=UTF-8

Also, since

public interface Schedule extends Identity {
    Association<Task> task()

then doesn't that mean that the Task must always be an Entity, and the
questions arise;
  1. Should we ONLY have Durable schedules??
  2. Should they really always reside in memory, or should "slow" schedules
be scanned at regular intervals? For instance, schedules executing with
minute granularity are checked once a minute, those that are executing with
hour granularity are checked once every hour, and so on?


Cheers

On Thu, Jun 25, 2015 at 4:13 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> Paul,
> is it a few minutes effort for you to add a
>
>     void removeSchedule( Schedule sch );
>
> to the Scheduler?
>
> Otherwise I need to dig into whether there are any details of how it works
> and anything that must be thought of, for both Durable and non-Durable
> schedules, i.e. understand everything.
>
>
> Btw, I have fixed that passivation is handled properly, because it
> actually prevented applications from shutting down cleanly.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a113ef45ab3f7550519536c38--