Scheduler library

[Niclas Hedhman <ni...@hedhman.org>]

Gang,

I have overhauled the Scheduler library, because it behaved very weirdly
before, for instance loosing the tasks permanently and other issues.

The previous version can be checked for problems, just by schedule more
than one "OnceSchedule" in the test case and it won't work.

Now, to sort out the problem, I decided to drop the "transient" case,
mostly because one can use java.util.concurrent executors for that. We
could possibly add it back later.

The TaskRunner is handling the execution state machine, and it is NOT nice.
Primarily because I think it is crucial to detect "overrun", i.e. the Task
is still running when it is time to run it again, skip the new run and
indicate (in a counter) that it has happened. That creates a mess of
UnitOfWorks, and takes a long time (15-20ms on my old MacBook) to execute.
Better ideas on how to achieve this is most welcome.

I have updated the docs, but a proof-read and touch up would be good. I
have not re-generated the 'latest' website.

The reason for all this work is because my application I am working on is
heavily dependent on this library, so I want to thank Paul for creating it
in the first place.


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

Re: Scheduler library

[Paul Merlin <pa...@nosphere.org>]

Niclas Hedhman a écrit :
> Ok, I'll take that into consideration when I get there.
>
> I have had even more strange behaviors related to this, questioning my
> sanity.
>
> In FileEntityStoreMixin, there is a getDataFile() followed by an
> f.exists(). My code executes past that point (file does exist) but a few
> lines later (in fetch()) the "new FileInputStream" throws a
> FileNotFoundException. If I debug through the section of code, then the
> FileNotFoundException is not thrown. If I put in an extra check at the call
> to "new FileInputStream" the file exists.
> If I catch the "EntityStoreException" that results in this, and immediately
> call uow.get() again, then the call succeeds (every time).
>
> Unfortunately, the "try again" is needed inside the Scheduler for my
> application, and that is simply not a work-around that I can tolerate, so
> ....
Huh...

> All-in-all, far too much time spent on this (5 full days by now). Why isn't
> Quartz used again?? LoadSchedules from disk, create a Quartz task for each,
> injected with the appropriate Module... Is that too easy? ;-)
I created the scheduler library way back in 1.x times. It was very
different than it is now, slow but served its purpose back in the days.
After that you rewrote this library for 2.0, refactored it for 2.1 and
now looks like you are rewriting it again. I feel your pain. A Quartz
integration would do, I don't recall why I rejected Quartz in the first
place years ago.

Cheers

/Paul

Re: Scheduler library

[Niclas Hedhman <ni...@hedhman.org>]

Ok, I'll take that into consideration when I get there.

I have had even more strange behaviors related to this, questioning my
sanity.

In FileEntityStoreMixin, there is a getDataFile() followed by an
f.exists(). My code executes past that point (file does exist) but a few
lines later (in fetch()) the "new FileInputStream" throws a
FileNotFoundException. If I debug through the section of code, then the
FileNotFoundException is not thrown. If I put in an extra check at the call
to "new FileInputStream" the file exists.
If I catch the "EntityStoreException" that results in this, and immediately
call uow.get() again, then the call succeeds (every time).

Unfortunately, the "try again" is needed inside the Scheduler for my
application, and that is simply not a work-around that I can tolerate, so
....


All-in-all, far too much time spent on this (5 full days by now). Why isn't
Quartz used again?? LoadSchedules from disk, create a Quartz task for each,
injected with the appropriate Module... Is that too easy? ;-)


Cheers
Niclas

On Tue, Nov 17, 2015 at 1:41 AM, Paul Merlin <pa...@nosphere.org> wrote:

> Niclas,
>
> Niclas Hedhman a écrit :
> > A heads-up...
> >
> > Still not working properly. Some initialization issues and also that the
> > Cron routine returns "now" if "now" was just executed. Need to push it
> > forward one second for it to grab the next point in time.
>
> About that second forward, it looks like a mismatch between Zest
> CronShedule::nextRun() method contract and the one of the underlying
> cron library ::firstRunAfter() method.
>
> I reworked the code so this mismatch is isolated under ChronSchedule
> implementation, close to the underlying cron library.
>
> /Paul
>
>


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

Re: Scheduler library

[Paul Merlin <pa...@nosphere.org>]

Niclas,

Niclas Hedhman a écrit :
> A heads-up...
>
> Still not working properly. Some initialization issues and also that the
> Cron routine returns "now" if "now" was just executed. Need to push it
> forward one second for it to grab the next point in time.

About that second forward, it looks like a mismatch between Zest
CronShedule::nextRun() method contract and the one of the underlying
cron library ::firstRunAfter() method.

I reworked the code so this mismatch is isolated under ChronSchedule
implementation, close to the underlying cron library.

/Paul

Re: Scheduler library

[Niclas Hedhman <he...@gmail.com>]

A heads-up...

Still not working properly. Some initialization issues and also that the
Cron routine returns "now" if "now" was just executed. Need to push it
forward one second for it to grab the next point in time.

Just want to let you know that I am working on it, and need to have solved
by tomorrow... Spent too much time on it already. :-(

Cheers
Niclas
On Nov 14, 2015 12:46, "Niclas Hedhman" <ni...@hedhman.org> wrote:

> Gang,
>
> I have overhauled the Scheduler library, because it behaved very weirdly
> before, for instance loosing the tasks permanently and other issues.
>
> The previous version can be checked for problems, just by schedule more
> than one "OnceSchedule" in the test case and it won't work.
>
> Now, to sort out the problem, I decided to drop the "transient" case,
> mostly because one can use java.util.concurrent executors for that. We
> could possibly add it back later.
>
> The TaskRunner is handling the execution state machine, and it is NOT
> nice. Primarily because I think it is crucial to detect "overrun", i.e. the
> Task is still running when it is time to run it again, skip the new run and
> indicate (in a counter) that it has happened. That creates a mess of
> UnitOfWorks, and takes a long time (15-20ms on my old MacBook) to execute.
> Better ideas on how to achieve this is most welcome.
>
> I have updated the docs, but a proof-read and touch up would be good. I
> have not re-generated the 'latest' website.
>
> The reason for all this work is because my application I am working on is
> heavily dependent on this library, so I want to thank Paul for creating it
> in the first place.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>