polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: Scheduler Library upgrade?
Date Fri, 26 Jun 2015 11:09:32 GMT
Hi all,

> void removeSchedule( Schedule sch );
to do something more general (and good even in asynchronous contexts)
what do you think on add signatures/default implementation with
something using Subscriptions:

https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/api/src/main/java/org/reactivestreams/Subscription.java

this could be applied to many classes, to better align even with
ZEST-32 ( https://issues.apache.org/jira/browse/ZEST-32 ).

Just as idea ...


Bye,
Sandro

2015-06-26 9:51 GMT+02:00 Paul Merlin <paul@nosphere.org>:
> 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.
>
> Cheers!
>
> /Paul
>
>

Mime
View raw message