polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Scheduler Library upgrade?
Date Fri, 26 Jun 2015 07:51:11 GMT
Hey Niclas,
> 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.

Reading code ... ok, this library definetely needs some love...

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

I wrote this library for an application that needed a scheduler back in
2010. That application still runs Qi4j 1.x so I did not use the 2.0
version of this library...The 1.x implementation didn't hold any
Schedule in-memory. Itused both a pulse and a garbage collector thread
to persist/query/purge them instead ; cleaned the non-durable ones on
activation. It required both an EntityStore and an Index/Query engine as
both Task and Schedule were entities. It has worked reliabily for me
even with multiple instances of the same application hitting a shared
ES/I/Q. The distinction between Schedule & Task allowed to run frequent
and fast queries on Schedules even if the Tasks were big/complex entities.

At one point, you rewrote the library, starting from my implementation
in 2012 (f182bea503), and came up with something much more lean.But it
looks like some removed features still show through.Hence the confusion
I think. The unit tests, almost unchanged, cover the durable usage only.

Actual implementation use Schedule both as Value and Entity, for
non-durable and durable schedules respectively. It uses a scheduled
thread (next run) that is updated when adding a new schedule whose next
run is before its original target time. etc.. etc..

Anyway, the Scheduler Library needs an overhaul, that's for sure.



View raw message