I am running CF10 fully updated (10,0,11,285437) and I cannot get the <cfschedule> tag pause/resume to work properly. This is what I noticed at first, then I realized later the delete does not work either. I always get:
The following task could not be found: myTask.
I am running CF10 64bit and Apache 2.2 (32bit) on Windows Server 2008 R2 and I am running virtual hosts under a single IP. The <cfschedule> 'update' and 'list' tags work just fine as well do the 'pauseAll' and 'resumeAll' for groups. I unfortunately do not have another 64bit server to attempt setting this up on again and verify the issue. I'm hoping someone else can give me some ideas on where to go next here, because I really need to use this functionality and I've already had 1 other person tell me it works for them under CF10.
Please, any help or suggestions on what to try would be really appreciated.
<cfschedule action="update" task="myTask" group="myGroup" mode="application" interval="300" requesttimeout="60" startdate="01/01/2000" starttime="00:00:00" url="http://www.google.com" />
<cfschedule action="list" mode="application" result="tasks" />
<cfquery name="tasks" dbtype="query">
SELECT * FROM tasks
WHERE lower(task) = <cfqueryparam value="#lcase('myTask')#" cfsqltype="cf_sql_varchar" />
<cfdump var="#tasks#" /><br /><br />
<cfschedule action="pauseAll" group="myGroup" mode="application" /> <!--- Works --->
<cfschedule action="resumeAll" group="myGroup" mode="application" /> <!--- Works --->
<cfschedule action="pause" task="myTask" /> <!--- Fails --->
<cfschedule action="delete" task="myTask" /> <!--- Fails --->
Thanks in advance,
So, it turns out if you use 'mode' or 'group' attributes, you must have them to pause, resume, and delete the task, even if you are referencing them by thier name. Once I added 'mode' and 'group' it started working.
And 7 years later I stumbled on this and it saved my day!
Hey, Steve, can you report what version of CF you are on? Am just curious if this solution is still needed in CF2018 (or 2016 or 2021 or 11), versus what Daniel reported here back in 2013 and CF10. (To be clear, I have not tested it and just thought it would be faster to ask then to set about doing that in the different versions.)
I can attest that problems like this still exist in the cfscheduler.
However, where you really run into problems is if you want to pause a task, and then later resume it as while you can pause the task if you include the group name, you then get the following error if you try to resume it:
"The following task has expired and could not be paused or resumed"
I've yet found a way around this error. I get it whether I try to resume from the CF Admin or via a cfschedule tag.
That is a bummer to hear, but thanks for sharing that, MJ. I'd recommend you go ahead and create a ticket at tracker.adobe.com.
(Despite assertions by many, it's not "a waste of time to bother". Adobe incorporates dozens of bug fixes each update, and therefore hundreds per year. Clearly they're not ignoring them all--though of course, anyone who finds their bug ignored would think that "Adobe pays no attention to them".)
I will be anxious to hear about the solution. All schedulked tasks gone and error on trying to access in the adminstrator.
Yours is not the same problem as this. A solution for this problem was offered above...and may have been addressed even more easily as of an improvement in cf2021 or perhaps an update to 2018. (I don't know and have not checked.)
But as for your problem, I suspect you'll find the neo-cron.xml file got corrupted and may well be empty: it's in cfusion/lib (or [instancename]/lib).
As for how it becomes corrupted, it can happen if cf crashes or is killed while that file is being written to.
I raised a bug about it, and Adobe did say they addressed it. I offer more details there.
But what cf version are you on? And what update?
As for resolving it, you may be out of luck if you have no os-level file backups to restore from. While there is one backup file kept by cf for each neon file, any attempt to write to the file again (or even just a cf restart) can lead that bak file to be overwritten with the corrupted/empty one. This too is something I raised in the bug report:
A last resort could be if you have other cf versions that have the same scheduled tasks. If it's the SAME cf version and update, you could stop this cf, copy in that neo-cron.xml, and start this cf. If they're NOT the same cf version, copying xml files across different cf versions is unwise as the format may have changed.
Let us know what you find.