tracker issue : CF-3852672

select a category, or use search below
(searches all categories and all time range)

[ANeff] ER for: scheduler to create _instances_ of handler

| View in Tracker

Status/Resolution/Reason: To Fix/Fixed/BugReVerified

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 11/17/2014

Components: Scheduler

Versions: 2016,11.0

Failure Type: Data Corruption

Found In Build/Fixed In Build: CF11_Final / docs

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 1

1) Currently, when a task w/ a handler triggers, scheduler doesn't create an _instance_ of the handler before calling its methods.
2) <cfschedule action="list" returns LAST_FIRE as the last time the task triggered, but multiple instances of the task could be running simultaneously.
3) What if, within the handler's onTaskEnd() or onError(), developer wants to know how long _this instance_ of the task ran?

Well, if scheduler created a handler _instance_ each time the task triggered, then we could do this:

component implements="cfide.scheduler.ITaskEventHandler" {
  boolean function onTaskStart(struct context) {variables.taskStartedAt=now(); return true;}
  void function onMisfire(struct context) {}
  void function onTaskEnd(struct context) {//use variables.taskStartedAt to determine duration b/c task's last_fire may not be the timestamp of when _this_ instance of the task began running}
  void function onError(struct context) {}
  void function execute(struct context) {}

Meaning, we could create a timestamp in onTaskStart() and access it in onTaskEnd()/onError().

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3852672

Reason:	BugVerified

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:



If this is implemented, it'd also be helpful if there's a way to get a handle on these instances. Maybe something like <cfschedule action="listinstances" task="mytask" result="q" /> which could either: 1) return an array of the instance objects -or- 2) return same query as action="list", but have a row for each instance and LAST_FIRE would be the timestamp that _that instance_ was triggered Thanks!, -Aaron
Comment by External U.
10068 | November 17, 2014 05:50:35 AM GMT
Also, if this is implemented, then CF Admin's tasks page could possibly display an indicator bulb next to each task that was triggered and is still running :) Thanks!, -Aaron
Comment by External U.
10069 | November 18, 2014 02:26:31 AM GMT
I'm having a really hard time finding any meaningful documentation about implementing the ITaskEventHandler interface. From what I can tell, scheduled tasks created with the eventhandler="some.component.Path" approach don't pick up on any application scope, even when created within the context of an application (mode="application"). Is this by design, and if so, what's the value in specifying application-specific scheduled tasks? I _want_ to use these cool new features in CF, but from what I can tell, there's nothing this provides that the URL-based approach doesn't already offer.
Comment by External U.
10070 | March 27, 2015 02:51:20 PM GMT
I'm running into the same/similar issues as Aaron has noted... I'd definitely appreciate some more documentation, as well! :D
Vote by External U.
10071 | March 27, 2015 02:52:34 PM GMT
Hi External User (doesn't show your name), Task handler does share application scope, as shown by Thanks!, -Aaron
Comment by Aaron N.
27734 | May 10, 2018 08:19:56 AM GMT
Creating instance on each run will be an over kill.   Now we will pass one more attribute to the struct in each method of the event listener : fireinstanceid   This will be unique ID of the current task run(instance).   It can be used to create a map of intanceId and other info (like timestamp)
Comment by Uday O.
27737 | May 10, 2018 12:16:32 PM GMT
Hi Uday, w00t!!!! Thanks very much!!!! Also, a variable created in one method can be accessed in another method? That too? Or not? Hopefully that can also work.. Thanks!, -Aaron
Comment by Aaron N.
27738 | May 10, 2018 06:40:21 PM GMT
@aaron Yes, variables can be now accessed across the methods defined in the listener
Comment by Uday O.
27815 | May 15, 2018 10:54:03 AM GMT
The fix that alllowed  variables to be accessed across the methods defined in the listener was reverted because of few issues reported by users .Hence , we have re-opened the bug. However , "fireInstanceID" is still passed as an attribute to the struct in each method of the event listener.  Thanks, Suchika
Comment by Suchika S.
30658 | April 25, 2019 11:50:26 AM GMT