Ok so I puzzled out what was wrong, and it was pretty damn annoying! It seems that the startup order was set for the web app to run before the scheduler. This meant that when the web app initialised, it looked to subscribe to the scheduler but, as the scheduler was not yet initialised, simply dropped the subscription. This meant that subsequent calls to Bus.Instance.Publish(…) did squat.
Two quick fixes:
1. Make sure the scheduler always starts up before the web app
2. Call the scheduler’s end point directly, using:
ScheduledTaskId = task.Id,
Crontag = task.Crontag
Note: probably not the best idea to hard code the uri, add it to your config instead!
So I’m currently writing a command line task scheduler so users can get various reports emailed to them at specific times. In order that the scheduler was not continuously polling the database to check for new scheduled tasks, I needed to be able to communicate from the web app to the scheduler whenever a new task was created/a task was edited, and decided to use Mass Transit for this. Mass Transit is a really easy way to set up service bus implementation, used to pass messages between parts of the system running as different processes/on different machines.
For whatever reason, I really love asynchronous stuff, it just seems so cool. So when I update a scheduled task and I see the change reflected in my command line app its pretty exciting.
When I come in to work the next day, and it doesn’t work anymore despite no code changes, it’s a real pain in the ass…