This is a good addition to .NET - the Stack Overflow scheduler is based on IHostedService, and we have a lot of other plans for it too.
Some examples of queues we have at Stack:
- The aggregator, which puts stuff in network-level tables for things like reputation in your top bar.
- Account queues, for merging/deleting users and such.
- GDPR request completion
- Elasticsearch indexing
- Related question rebuilds
- The aggregator, which puts stuff in network-level tables for things like reputation in your top bar.
- Account queues, for merging/deleting users and such.
- GDPR request completion
- Elasticsearch indexing
- Related question rebuilds
We've moved them to a common "service" type implementation with shared logging, locking, and status reporting infrastructure. They're currently async/await Task.Delay style node competition services we'll move to IHostedService in the move to #AspNetCore.
When you consider our deployment scenarios, options this enables become very appealing.
Scaling up or out in prod? Separate scheduler instance that does a lot of work.
Running local or Enterprise with a few sites? Just fire up the scheduler IHostedService in-process on startup.
Scaling up or out in prod? Separate scheduler instance that does a lot of work.
Running local or Enterprise with a few sites? Just fire up the scheduler IHostedService in-process on startup.
When we built the new Stack Overflow scheduler, it's in 3 projects: SDK lib (a .nupkg, minimal classes needed to interface with it as an API), the IHostedService bits (also a .nupkg), and a very thin #AspNetCore site that runs the middle package on startup. That's all it does.
So now, we can make things that can run elsewhere as a dedicated/beefy service, or do the same work in-process for smaller deployments with simpler infrastructure. Trivially. It's so pluggable.
We love it. Can't wait to finish this move...so many wins in .NET Core.
We love it. Can't wait to finish this move...so many wins in .NET Core.
Been asked a few times: will we open source the scheduler? Yeah, maybe. It's really not specific to us at all. It just supports a multi-tenant infrastructure especially well. It'll probably end up on GitHub a bit later when we have the time and fully vet all the combos here.
