Proposal for a system scheduler class (OSchedule or OCronjob) which contains links to OFunctions together with a Linked Class, an argument array, and Cron job style rules.
These functions would be called periodically according to the cron rules and the output logged in an logging class (OLog or OChronLog) as records with a timestamp and linked back to the calling Schedule job.
These functions could be used to perform many very usefull thinkgs like
what can be the advantages of integrating, for example, a http://quartz-scheduler.org/ into the OrientDB core vs running it as an independent sotware? Any options to make it pluggable at will?
Seems like a good way to go, but I think it is important the the functions should be defined as OFunction's and registered using a system class like OSchedule, to make it easy to manage everything remotely via the studio.
this is another good point! @pellyadolfo I usually think 10 times before adding a new library to OrientDB. Since all we would need form Quartz is its cron like syntax, I think we could implement it by our own or find a lighter library.
Ok, Luca I agree with a custom engine as quartz is oversized.
I found this library of 211kb: http://www.sauronsoftware.it/projects/cron4j/manual.php#p14
Could it be enough?
I moved this issue in the next 1.4 because it's easy to implement and offer huge gain for OrientDB Web apps.
We got this one. Henry will be requesting a pull early next week. As a heads up we are only using a couple of classes from cron4J which is LGPL so some kind of attribution notice will be required.
cron4j sounds good. Waiting for such pull request ;-)
I'm following this thread and I was wondering what will happen in a distribute scenario.
I.E. in a cluster scenario data in the new OSchedule class will be duplicated across the nodes, each node will attempt to execute the scheduled tasks and will perform the associated functions, possibly, because of this, modifying data in other classes, which in their turn, should be propagated to other nodes, producing conflicts or something similar.
Could this be a real problem?
How to avoid this?
Right now the only way to control the scheduler in a cluster is via the config files for each instance. The scheduler should be enabled in one instance but not in the others. Once we have a little more clarity and stability with the way the DHT index is implemented we can be a little smarter about about this.