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 <[email protected]>: > 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 > >
