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
Date Tue, 17 Nov 2015 00:17:22 GMT
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 <paul@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

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