Viewing By Entry / Main
January 25, 2006

I use the ColdFusion scheduling service quite a bit. For one of our applications, we have over 500 scheduled tasks that execute daily, controlling the generation and distribution of reports. Because of the frequency with which I use the scheduler, I've compiled a list over the years of features I'd love to see added to the current implementation:

  • Ability to sort tasks in the ColdFusion Administrator view - by task name and by interval, both ascending and descending
  • Ability to put a scheduled task on hold. Currently there's no way to temporarily disable the execution of a schedule task without deleting it (or changing the execution URL to a non existent page).
  • Addition of weekday and weekend only durations. Currently, you can schedule a task to execute daily every n hours/minutes/seconds, but there's no way to specify you want this to occur only Monday through Friday (business days) or only on Saturday and Sunday. Sure you can code this into the pages you are executing, but that code has to be used with each task. It's much better if this can be made part of the scheduler.
  • Task execution redundancy. Currently, if a scheduled task fails to execute (for instance if the server is being rebooted during execution time), there's no mechanism in place to automatically attempt to re-run a task. I've built this type of redundancy into several applications I've written that have scheduled tasks, but again, it has to be done on a per application/per server basis.
  • Better reporting on task execution. I'd love to see a new column on the ColdFusion Administrator page for scheduled tasks that shows the last date/time the task was successfully executed as well as the next date/time the task was scheduled to execute. This would be invaluable for monitoring and troubleshooting.

I know that this list is by no means exhaustive. What would you like to see added to the ColdFusion scheduler?

Comments
Peter Tilbrook's Gravatar Rob, all great ideas, you should forward this to Damon, Tim, Mike, et al.
# Posted By Peter Tilbrook | 1/25/06 5:03 PM
Sean Tierney's Gravatar Rob,
have you considered creating just one scheduled task which calls a page that checks a queue of tasks and executes each one when necessary? I did something like this for Saleslogix.com and it worked great. You can solve all the problems you mention:
-Ability to sort tasks = they're stored in the db (or elsewhere in a structured format) so you can sort and display however you want
-put a scheduled task on hold= read in all tasks but only execute the ones that have status flag of active
-weekday and weekend only durations = would be a function of how you implement the scheduling. Blayter actually wrote all this in a fusebox calendar app he tweaked a long time ago. You might ask him for that code, i bet he wouldn't mind sharing.
-execution redundancy = simple. don't remove it from the queue until you know it has executed successfully. when you check the queue, you're looking for tasks that have not executed and have a run date of now or earlier
-Better reporting on task execution = log the results of each operation and create whatever reports you like since it will just be an entry in the db. would be trivial to use cfchart to run various views on the log table

anyways, i know it's not pre-built and for free in the administrator but that's definitely one way to do it. this type of thing actually seems like an ideal candidate for Ryan Guill's COAL system as it's a reusable service that i'm sure others would find useful.

Sean
# Posted By Sean Tierney | 1/25/06 5:32 PM
Rob Brooks-Bilson's Gravatar Hi Sean,

We've actually built most of that functionality into our app as well - with the exception of the 500+ tasks in teh admin vs. a single one that checks the queue. The reason for so many tasks is because many of them take several minutes to execute (very large recordsets and db intensive reporting), and multiple tasks can be scheduled for the exact same time. We had originally gone the single task route, but it caused severe performance issues because it essentially single threaded the requests, creating one big queue that had to execute sequentially. Since any number of tasks can be scheduled for the same time slot, if there were 10 tasks set for 10pm, it could take quite a long time for those tasks to execute, thowing off the entire schedule.

With the introduction of the asynch gateway in CFMX 7, we can now get around this, but haven't really needed to go back into our system to redo the functionality (cost of maint vs. cost of new development).
# Posted By Rob Brooks-Bilson | 1/25/06 6:01 PM
Steve Moore's Gravatar "Ability to put a scheduled task on hold" - Why not just set an end date that has passed and erase it to resume?
# Posted By Steve Moore | 1/26/06 8:41 AM
Patrick Correia's Gravatar @Steve - I second your suggestion; I do this all the time to temporarily put tasks on hold.

My biggest request is better logging (similar to your point on reporting). My wish for logging is a system like web server logging, which would include:

- Appending to a single log file each time the task runs. You could specify the logging location, so you could make one log file for each task or one big one for multiple tasks.
- Rotating log files by date.
- Customizable columns, including HTTP status code and the first X characters (or the first line) of the response.

Building on the idea of leveraging event gateways, why not have a simple drop-down in the administrator that allows you to choose a gateway instance that would be passed a message each time a scheduled task completed (or failed)? This would give me all the flexibility I want, and also provide a hook for all sorts of other interesting integration like emailing or paging an administrator when a task failed. Of course, under the current licensing it would be Enterprise-only :o(
# Posted By Patrick Correia | 1/26/06 2:42 PM
Rob Brooks-Bilson's Gravatar Hi Steve - that's essentially what we're doing now for one of our apps (we "expire" tasks), but when you have tons of tasks setup, it is difficult to scan through the list and determine what's "on hold" by looking through a see of dates. I'd like to see something a little cleaner implemented as part of the native functionality.

Patrick, I think there's a key word in your post - MESSAGE. To me, messaging (in the JMS sense) is something not a lot of CF developers are doing yet, but I see huge potential for. As you mention, firing off messages when events happen would allow for all sorts of cool things. It can be done now, but you need to understand JMS, be able to setup a JMS server, and then use something like's Sean Corfield's JMS gateway to connect them all together. Possible, but not simple for your average CF developer.
# Posted By Rob Brooks-Bilson | 1/26/06 3:08 PM
barry.b's Gravatar Rob: Exellent ideas: can I please ask of you to make Tim Buntel aware of them? I'm sure most would be easy enough to do

just my 2c worth.
# Posted By barry.b | 1/29/06 5:02 PM
Rob Brooks-Bilson's Gravatar Thanks Barry. I'm pretty sure I've sent most of these in via the wishlist or previous beta's, but I'll be sure to forward to the CF team again, just to be sure ;-)
# Posted By Rob Brooks-Bilson | 1/29/06 8:38 PM
Paul Carney's Gravatar Rob,

As with others, we have created a system to get around some of your items. We also would like to see the scheduler updated (along with the cfschedule tag) to handle some of these items from an application server level than to have to build our own.

One item I would request: a unique (UUID) for a task in addition to its "task" name. The "task" attribute is more of a title, but it would be easier to have a separate UUID that we can use to tie back to a scheduled task.

Nit-picky, but hey, while you are compiling a list....
# Posted By Paul Carney | 2/2/06 10:43 AM
Rob Brooks-Bilson's Gravatar Thanks Paul - another good idea. The title can be a problem, especially in shared environments. We've taken to using an application identifier along with a UUID to make it both human and application friendly, but I agree that an identifier separate from the title would be very useful.
# Posted By Rob Brooks-Bilson | 2/2/06 10:47 PM
Sam's Gravatar My company would like coldfusion to schedule a task to execute a cmfx page on our server, however this is not possible since cfschedule does not support ssl which we use. I'd like to see it either be enabled to support https connections or execute a file on the server instead of executing a url. Neither are supported and yet both would be convenient. I realize windows task scheduler and linux cronjobs can also be used, but it was a step we would wanted to avoid since we are creating an administrator page for our clients with an option to start the automation of the process.
# Posted By Sam | 3/10/06 3:52 PM
Rob Brooks-Bilson's Gravatar Sam,

I haven't tried this myself, but I'm thinking that since CFSCHEDULE uses CFHTTP under the covers, that it should be possible to do if you follow the procedure for enabling SSL for CFHTTP. More can be found here:

http://www.bpurcell.org/blog/index.cfm?mode=entry&...

http://www.houseoffusion.com/cf_lists/index.cfm/me...=messages&threadid=13865&forumid=4%3E%20&threadid=13865&forumid=4&threadid=13865&forumid=4
# Posted By Rob Brooks-Bilson | 3/15/06 4:25 PM
Rob Brooks-Bilson's Gravatar Hi Sam,

Just one more update. I came across this technote yesterday that might help:

http://www.macromedia.com/cfusion/knowledgebase/in...

It seems to imply that it's possible to call an SSL page using the scheduler since it implements CFHTTP behind the scenes.
# Posted By Rob Brooks-Bilson | 3/16/06 5:41 PM
Stacy Young's Gravatar Ability to specify the storage mechanism for schedules. I'd very much like database over xml files ...perhaps kill two birds with one stone by using a JMS clustered queue with JDBC storage which gives us fault tolerance and ditches the xml?
# Posted By Stacy Young | 7/25/06 9:15 AM



Copyright 1995-2008 Rob Brooks-Bilson. All rights reserved.
Aura skin for Raymond Camden's BlogCFC inspired by Joe Rinehart & Steven Erat. This blog is running version 5.5.1.