polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Scheduler Library upgrade?
Date Fri, 26 Jun 2015 11:29:54 GMT
Ok, so to explain; The Scheduler Library is effectively a "Cron Job"
thingy, where I can tell it to execute something in the future, either once
or periodically. Those registrations survive restarts, as they are entities
(although there seem to be intent to support Values, which may be a
mistake).
Not sure how that relates to Reactive Streams per se, which deals with
feeding a stream of events through a system.

I realize that the suggested method signature is not good, since that means
that someone else need to save the Schedule entity somewhere. This might
have been the reason it was left out in the first place.

Another thing is whether the Task should be able to cancel itself... Not
sure. But that would need a different design as well.

Niclas


On Fri, Jun 26, 2015 at 1:09 PM, Sandro Martini <sandro.martini@gmail.com>
wrote:

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



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message