tracker issue : CF-4197250

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

[ANeff] Bug for: tasks can run off-schedule

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

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

Created: 11/02/2016

Components: Scheduler

Versions: 2016

Failure Type:

Found In Build/Fixed In Build: CF2016_Update3 / 2020.0.0.314573

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Win All

Vote Count: 0

A task having "On Misfire" set to "Fire Now" or "Invoke Handler" runs off-schedule in these cases:

I) The task was just created (via both CF Admin and cfschedule)
II) The task was just updated (via both CF Admin and cfschedule)
III) Every time CF starts, if the task is not paused (3141655 fixed the issue for paused tasks)

Steps to Reproduce:
1) Create a task w/ onmisfire="firenow" (via either CF Admin and cfschedule)
2) See scheduler.log shows the task misfired and then fired
3) Edit the task (via either CF Admin and cfschedule)
4) See scheduler.log shows the task misfired and then fired
5) Restart CF
6) See scheduler.log shows the task misfired and then fired

To further verify, just have the task hit a page that sets SERVER.foo=now(). Then, at steps 2/4/6, see SERVER.foo's timestamp updated.

If CF Admin isn't using the Admin API for this, then the Admin API should also be checked/fixed.

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

Watson Bug ID:	4197250

External Customer Info:
External Company:  
External Customer Name: Aaron Neff
External Customer Email:

Attachments:

Comments:

Verified in CF2016 Update 3 (build 2016.0.03.300466).
Comment by External U.
1508 | November 02, 2016 05:46:22 PM GMT
Hi Aaron, This scenario may occur if there is a system time mismatch or when a daily task is created which was supposed to run the same day before it was created . Hence , the task misfired . Please confirm if your scenario was same as above. If not , then please send us the repro case . Thanks, Suchika
Comment by Suchika S.
1509 | March 09, 2017 09:26:52 AM GMT
ADOBE, You NEED to send out pending comment/vote notifications. The fact that your new tracker didn't have notifications implemented before going into production, doesn't mean that the notifications that should've been sent should just fall into the void. I was never notified of Suchika's comment. That's b/c the new tracker's notification system wasn't setup yet to send notifications to 3rd part (aka non-Adobe) commenters/voters. Suchika, I'd reported this ticket's issue during the same prerelease wherein event handlers were added. Did you try the steps in the description? Nevertheless, I'll work on some code. This long standing issue needs fixed. Thanks!, -Aaron
Comment by Aaron N.
1510 | May 19, 2017 08:53:56 PM GMT
Hi Aaron , Did you get a chance to produce a repro case? However I would just like to let you know that a task misfires if it was was scheduled with start time in the past and every time you restart you CF server all non clustered tasks are re -created . Hence the tasks that have start time in the past misfire . Thanks, Suchika
Comment by Suchika S.
1511 | October 05, 2017 10:44:49 AM GMT
Hi Aaron, I am not able to reproduce the bug and hence closing it . If you are still facing the issue , let us know . We will re-open the bug. Thanks, Suchika
Comment by Suchika S.
1512 | January 23, 2018 06:30:06 AM GMT
Hi Suchika, Sorry I just saw your comment. Repro is simple. Just create a task in CF Admin. Leave it running (don't pause it). Then restart CF. See in the logs that it misfired. CF shouldn't misfire tasks on restart, b/c it could cause an unexpected issue if one's using handlers to refire misfired tasks. Thanks!, -Aaron
Comment by Aaron N.
27561 | April 29, 2018 07:26:59 PM GMT
Also, editing an already-ran task shouldn't cause it to misfire. I realize Adobe will say "expected behavior" (b/c start date was in the past). But, the problem is due to the unclean way in which CF handles creation/updating of tasks. Which can also lead to neo-cron.xml corruption, etc. Thanks!, -Aaron
Comment by Aaron N.
27562 | April 29, 2018 07:33:20 PM GMT
Hi Suchika, I followed-up as requested, but you didn't re-open the bug? Can you please re-open? Thanks!, -Aaron
Comment by Aaron N.
27731 | May 10, 2018 01:19:07 AM GMT
Hi Suchika, I've attached repro 20181122_3336193.zip Could you please read readme.txt and confirm? Thanks!, -Aaron
Comment by Aaron N.
29959 | November 22, 2018 08:11:01 AM GMT
Sigh, the task in 20181122_3336193.zip broke CF2018's "Edit Tasks" page :( In CF Admin, if I try to edit that now-expired task, I get: java.lang.NullPointerException ----------- The error occurred in scheduleedit.cfm: line 879 Called from scheduleedit.cfm: line 800 Called from scheduleedit.cfm: line 758 Called from scheduleedit.cfm: line 1 -1 : Unable to display error's location in a CFML template. ----------- ??
Comment by Aaron N.
29960 | November 22, 2018 08:25:39 AM GMT
Repro for above comment: 1) On "Settings" page, check "Enable Null Support" and click "Submit Changes" 2) On "Scheduled Tasks" page, try to edit 20181122_3336193.zip's task. 3) See java.lang.NullPointerException (bad) 4) On "Settings" page, uncheck "Enable Null Support" and click "Submit Changes" 5) On "Scheduled Tasks" page, try to edit 20181122_3336193.zip's task. 6) See edit page displayed (good) So.. NULL support somehow breaks "Edit Tasks" page. Hopefully someone is still monitoring this ticket b/c I might forget in a few months or years from now =P Thanks!, -Aaron
Comment by Aaron N.
29961 | November 22, 2018 08:30:43 AM GMT
Hi Suchika, Regarding your above comment ("a task misfires if it was scheduled with start time in the past and every time you restart you CF server all non clustered tasks are re -created."), right, _that_ is the problem. CF should NOT be re-creating tasks on restart. I sure hope CF-3434100's fix will allow CF to _not_ auto-recreate tasks at startup? The issue, of CF mistakenly misfiring tasks, has existed since the prerelease that added task handlers. I reported it during that PR and have banged on about it ever since =P It's just not right. CF's behavior is so wrong here.. :( Thanks!, -Aaron
Comment by Aaron N.
29962 | November 22, 2018 08:59:25 AM GMT
Hi Adobe, Thank you very, very much for re-opening! Please let me know if I should log a separate ticket for CF Admin's java.lang.NullPointerException (mentioned above in earlier comment). Thanks!, -Aaron
Comment by Aaron N.
29994 | December 04, 2018 05:22:24 AM GMT
Hi Aaron, Yes, you can raise separate bug for NPE. Non clustered tasks stay in memory. Once server is stopped, they are gone. So on restart these tasks need to be created again Thanks, Uday
Comment by Uday O.
30694 | May 07, 2019 09:28:34 AM GMT
Hi Uday, Thank you for confirming the NPE. CFRestart != TaskMisfire. If you are a CF end-user, do you want your onmisfire="firenow" tasks misfiring when CF restarts or the task's definition changes? This ticket should be fixable now that CF stores a task's definition separately from its history. Right? Thanks!, -Aaron
Comment by Aaron N.
30696 | May 08, 2019 10:12:05 PM GMT
To be clear: I reported the same behavior that you're describing, during CF10 PR. Rather than all of us re-stating the current behavior, could you please view this thru the lens of a CF end-user?
Comment by Aaron N.
30697 | May 08, 2019 10:17:34 PM GMT
Hi Adobe, CF-3434100 added action="modify". CF restart, and action="modify", should now honor LastRan metadata, and not mistakenly misfire a task. Thanks!, -Aaron
Comment by Aaron N.
30704 | May 09, 2019 05:25:17 AM GMT