Closed Blacksmoke16 closed 5 years ago
~Noticing an issue where its doing 1 more execution than it should sometimes, i'll look into it.~
EDIT: Fixed in b4930ce
Any reason why this hasn't been merged yet?
IIRC I need to write tests for it, but was dependent on another shard being updated, that has since been forked and update.
I been using it for past few months and it's been fine as far as i can tell. However, not sure on the best way to test this, and hasn't been a high priority of mine lately :/
@robacarp This should be good for review again when you get some time.
Resolves #1
WAITING
queue to actually bewaiting
, is more clear.~However the more i think about it the one thing this wouldn't solve well is if the tasks get added slowly. For example you have a job that is set to 10 executions per 60 seconds. But you add one every 10min. This implementation would still would wait 60 seconds before executing the 11th task.~
This has been solved, it now only counts executions within the given period seconds.
How this works:
@@mapping
class var to aclass_getter
var, as i needed a way to get a list of all defined jobsexecuted
field in the config objectTime.utc_now.epoch > (Time.epoch(config["last_executed"].to_i64) + config["period"].to_i.seconds).epoch
resetsexecuted
back to 0executed
==limit
, it will set theexecuted
field back to 0 and set thenext_batch
field to(Time.utc_now + period.seconds).epoch
q_config["next_batch"].to_i64 > Time.utc_now.epoch
and returns if trueWDYT @robacarp