I’m using CommandBox and CFConfig as my local dev environment for an app that creates scheduled tasks programmatically. It’s awesome, that you!
That said, I have two questions/possible problems:
Far as I can tell from the docs on Config Items, CFConfig doesn’t manage Tasks. Am I right about that? If that’s the case, I can manually tell the app I’m working on to recreate them. Is that the right plan, given the current state of CFConfig? Are there any plans to add services like tasks as config items?
That’s made a little less warm-and-fuzzy by the fact that those programmatically created tasks don’t show in Lucee Admin, at either the server or web levels, immeidately after creating them. Does it have anything to do with CFConfig? Is there anything you know of that I can do to fix it?
Scheduled tasks are supported by CFConfig on Adobe servers because a client paid me to add them,. Are you offering to pay for Lucee support to be added? I’ll likely get around to adding it at some point otherwise but it’s a low priority for me personally since I don’t use scheduled tasks. You can also take a stab at adding support via a pull request if you like. I’ve had probaby 3 or 4 people tell me they were going to do this but no pulls have come through yet for Lucee task support… BTW, that reminds me I need to update the docs to reflect some of the recent additions.
those programmatically created tasks don’t show in Lucee Admin, at either the server or web levels, immediately after creating them
Sorry, not following you. How are you creating them? Via CFConfig (which obviously won’t work) or via the admin UI, or via some CFML code? And were are you trying to see them?
Does it have anything to do with CFConfig?
CFConfig certainly doesn’t do anything to inhibit tasks from working as normal if that’s what you’re asking.
Is there anything you know of that I can do to fix it?
At this point I don’t understand what you’re asking
Thanks for your reply Brad. I get it about task support for Lucee, doubt my company would go for sponsoring that. I’m using CFConfig, but it’s not company infrastructure. Yet, maybe.
Re visibility in lucee admin, they’re getting created by cfml code, that’s what I meant by “programmatically created”. They appear to be running, but I can’t see them in lucee admin, in either scope.
I doubt that has anything to do with CFConfig, but since it’s happening I thought I’d ask. If not, it must be a CommandBox thing, I guess, but it is odd. Any ideas would be appreciated.
Sounds like a Lucee bug to me. I’ve never really created tasks programmatically so I’m not sure how to even test that. If you remove CFConfig entirely from he equation, does it still happen? (Just making sure nothing is getting overwritten). If you can produce it, I’d ask on the Lucee Discourse forum. Also, perhaps you can track down the XML file being used to store the tasks. I know “normal” scheduled tasks are in a scheduler.xml file and they are specific to a web context (never server). I’m not sure if the kinds of tasks you’re creating would also be in the same file or not.
Just shooting from the hip:
Sounds like a “Context” issue.
You might find the schedule tasks are being created just fine but are not displaying in the Lucee Admin because the schedule.XML has not been copied into the admin context for you to see them?
We have to do this (your paths might need a tweak) cp /opt/lucee/config/web/centra/scheduler/scheduler.xml /opt/lucee/config/web/luceeAdmin/scheduler/
I was looking at the commandbox scheduled task page. Will BOX need to be restarted for the scheduled tasks to take effect?
FWIW, I typically will create a scheduled task page on the websites, typically in the admin area, that will turn scheduled tasks on and off via cfschedule.
I think there’s some confusion here. What exactly are you using CFConfig for? Are you creating scheduled tasks in a running server? If so, yes a restart would be required. CFConfig only modifies XML files on disk, it doesn’t affect running servers’ memory.
This makes me wonder if you’re trying to create scheduled tasks in a SERVER or in the Lucee engine that powers the CLI. Restating the box CLI is not the same as restarting a server process.
I’m not quite sure what that has to do with CFConfig, but creating a scheduled task via CFConfig is no different than creating it in the Lucee or Adobe admin with the notable exception that the changes will not take affect right away.
You CAN have both Lucee and Adobe watch config files for changes BTW if you want.
I ended up on this thread when researching commandbox and scheduled tasks and I noticed I never responded.
When I asked if Box will need to be restarted that was poor wording on my part. I meant would I need to restart lucee via Box.
Yes, you are right, cfschedule via a page in the admin area doesn’t have anything to do with cfconfig. I imagine that was an unfinished thought.
Where I think I was going with that is would it be possible to create a box plugin that would use cfschedule behind the scenes to add/edit/delete scheduled tasks without having to do a server restart?
Lastly, Brad, you mentioned you do not use scheduled tasks. I am curious about what you use.
For clients who have moved to a scalable cluster or Docker setup, we’ve usually switched to an external scheduler like Jenkins. And, instead of hitting a URL, we rewrite their scheduled tasks to run as CommandBox Task Runners that can be executed directly on their Docker Swarm nodes independent of any web sites.
HI @bdw429s ,
Just to be clear (for me, and my naive understanding of all things Docker),
Does that mean that (your method of) Scheduled tasks - effectively run in their own container?
So the load of those tasks, don’t directly affect “your app”?
(assuming you have appropriate “machine” capacity for the extra “task” container(s)?)
Yep, each task is spun up in its own container instance. We have a docker image created on top of MiniBox that has all the task runners for all our tasks and then created multiple docker services using that image. For the daemon tasks that run 24/7 the service has one replica and an auto-restart policy. For the one-offs we run on a schedule, the docker service has 0 replicas and no restart policy. We “fire” the task by scaling the service up to 1. It runs and then quits when it’s done.
Even though this is part of a legacy app, they refactored all their core services (CFCs) into a separate repo/module which is shared by their web apps as well as the scheduled tasks (CommandBox can load up modules). This allows them to share their business logic layer across the board. There’s about 10-15 seconds of spool-up for the container/commandbox and then each task runs for a few minutes and shuts down. From a deployment perspective, there’s no relation between the web sites and the scheduled tasks other than the fact they’re hitting the same DB. We can scale each independently, and if they need more overall resources, we just add another node to the swarm, which is basically a VM running Docker. The absolutely great thing about docker is that our web server config (we have Nginx sitting out from) and our commands to fire off tasks don’t care if there’s a single swarm node or 50. All the network routing and distribution of new containers is handled by the swarm internally.
I’ll likely get around to adding it at some point otherwise but it’s a low priority for me personally since I don’t use scheduled tasks. You can also take a stab at adding support via a pull request if you like. I’ve had probaby 3 or 4 people tell me they were going to do this but no pulls have come through yet for Lucee task support… BTW, that reminds me I need to update the docs to reflect some of the recent additions.