Long Term Timers

Discussion in 'Spigot Plugin Development' started by Futurize, Apr 24, 2017.

  1. What would be the most efficient way to setup timers to go off every 24 hours or so? Not sure if making a countdown would be ideal as it would be removed when the server restarts. Also, how can I schedule stuff to happen on a certain date/time? Any help would be appreciated! Thanks!
     
  2. Use java timestamps.
     
    • Agree Agree x 1
  3. Make a Long type variable.

    Long delay = system.currentTimeMills() + (seconds * 1000);

    Or (minutes * 60) * 1000

    One second = 1000 ms,
    If you need this timer to persist through reboots you'll need to write it to disk/reload it when the server starts.

    Then just schedule a task to check the time every so often.

    If(System.currentTimeMills() >= delay)
    If this returns true your timer has expired and the code will execute. Be sure and reset the timer to a new value in the future.


    Sent from my iPhone using Tapatalk
     
  4. Alright. How about scheduling stuff to happen on a certain date/time?
     
  5. I had this issue a while back too, I endeed up writing a list of Dates when the timers should go off, and then I have a bukkitrunnable every 100 ticks or so checking if it's time yet, if it is it executes the task.

    Of course you load/save the dates on start and stop of server
     
  6. that was kind of a bad way of doing it.

    Always keep track of the next date when it's supposed to happen (in milliseconds). Everytime the server starts, you can build a runnable from this. It runs async. So your runnable is peristent.
     
  7. ..? Whats the difference between this and what I did?
     
  8. Sounds the same to me, run a runnable onEnable that checks every x amount of ticks if the time is equal to or greater than the time stamp.
     
  9. The list of dates is what's different. We can go off one timestamp, then just create the new (update) once that one has passed.
     
  10. What exp dev is suggesting is instead of scheduling a repeating task that checks every 100 ticks or so, convert your remaining timestamp into milliseconds and schedule a delayed task when your plugin starts up. This delay would be calculated by getting the delayed timestamp minus the current timestamp.

    That way your task doesent run every 100 ticks when it is not going to execute for 30 days.

    You would probably need to do:
    Delay - current time = msToGo
    msToGo \ 1000 = seconds
    Seconds / 20 = ticksOfDelay

    So when you schedule your delayed task to run it's delay would be set to ticksOfDelay instead of 100 or 20 like with a repeating task. It would fire ONCE and could reschedule itself and reset the delay when it ran. Instead of checking to see if it needed to run a million times a month.



    Sent from my iPhone using Tapatalk
     
  11. You can use the Java date class to add time to a date like x days then convert that to a unix timestamp. Then handle it just like described above.


    Sent from my iPhone using Tapatalk
     
  12. Oh, that's because my use case was a bit different, I had multiple long-term events. Obviously with one repeating event you cant just calculate all the days till infinity xD
     
  13. Well, practically you can if the event is to reoccur sequally with the same time in between.

    Code (Text):
    long now = System.currentTimeMillis();
    long event = now + 10800000; // 3 hours

    // event happened, update it:
    event = System.currentTimeMillis() + 10800000; // added another 3 hours. event should in theory be currentTimeMillis, but you can just use it again

    //event happened again, update:
    // etc...
     
  14. Did you even read my comment
     
  15. Yeah, you have multiple events, which also is possible. Have an incrementer for every event.