Timer Service for M5

Timer Service

For the time being, we will leverage the start event to launch the TimerService. This will be replaced with either a startDaemons event (as opposed to start), or a separate command altogether. These changes should only change which event the handler is configured for, and not any of the logic.

/config/handlers += [{
   "events" : ["start"],
   "handler" : "zero.timer.TimerService.class"
}]

Timer configuration

Timers are configured as a map of maps, where the key is the name of the task, and the value includes the period for repeat scheduling, and any instance data the task will need when it does execute. The instance data is specific to the type of task.

/config/timers += {
   "task1" : {
      "period":5, 
      "instanceData": {
         "resourceName" : "testFile", 
         "receiverURL" : "http://localhost:8080/resources/kick"
      }
   }
}

Timer task configuration

When a timer goes off, it fires a timer event, which needs a handler. The event data of the timer includes which task name has triggered the timer, which can be used to assign different handlers for different tasks if desired.

/config/handlers += [{
   "events" : "timer",
   "handler" : "zero.kicker.TimerKicker.class",
   "conditions" : "/event/_taskName =~ task1"
}]

Kickers

Kickers are configured as handlers which respond to the timer event. Kickers no longer need to implement any interface, they just need to respond to the onTimer event. Because all kickers share the need for POSTing data to a receiver, kicking functionality has been moved into a zero.kicker.Kicker class that individual kickers can leverage. It takes all the information a kicker needs to POST, including a map for data that is specific to a particular kicker. For instance, the TimerKicker, which always kicks on the timer event (no other conditions) has an implementation which looks like:

    public void onTimer() {
        String receiverURL = GlobalContext.zget("/event/receiverURL");
        String kickerName = GlobalContext.zget("/event/_taskName");
        String resourceName = GlobalContext.zget("/event/resourceName");
        Kicker k = new Kicker(receiverURL, kickerName, resourceName, null);
        boolean success = k.kick();
    }

The map in this case is null because there is no specific data to pass. Other kickers would follow this same pattern, substituting their own data.

Prototype implementation

A prototype implementation of the timer service and a TimerKicker is available from SVN in branches/b_messaging/zero.timer.

Ongoing considerations

The current kicker implements backoff behavior, increasing the timeout on failure. The current timer implementation does not offer this behavior. We know how to implement it, at this point its merely a matter of where the information on the new delay comes from... whether it comes from the handler for the timer event itself and the timer service asks the handler for it, or if it is part of the TimerService itself.