We're dealing with an interesting problem on StackOverflow.
We've got a whole bunch of little "needs to be done soon-ish" tasks. An example is updating "Related Questions" lists. What we've done in the past is to piggy-back those tasks onto some users' page loads.
This was never ideal, but it wasn't really noticeable. Now that SO has passed the 1,000,000 question mark, those unlucky users are starting to feel it.
The natural solution is to actually push these tasks into the background. There are two broad ways of doing this I'm considering.
1. In IIS as a custom Thread-Pool/Work-Queue
Basically, we spin up a few (non-ThreadPool, so as to not interfere with IIS) threads and have them services some collections we're shoving Funcs into.
The big pro here is simplicity. We don't have to worry about marshaling anything, nor do we have to make sure some external service is up and responding.
We also get access to all of our common code.
The con is, well, that we shouldn't use background threads. The objections I know of are all centered around starving IIS (if you use ThreadPool) and the threads dieing randomly (due to AppPool recycling).
We've got existing infrastructure to make the random thread death a non-issue (its possible to detect a task has been abandoned, basically), and limiting the number of threads (and using non-ThreadPool threads) isn't difficult either.
Moved to StackOverflow, as it wasn't really addressed here.
2. As a Service
Either some third-party solution, or a custom one.
Basically, we'd marshal a task across the process boundary to some service and just forget about it. Presumably we're linking some code in, or restricted to raw SQL + a connection string.
The pro is that its the "right way" to do this.
The cons are that we're either very restricted in what we can do, or we're going to have to work out some system for keeping this service in sync with our code base. We'll also need to hook all of our monitoring and error logging up somehow, which we get for free with the "In IIS" option.
Are there any other benefits or problems with the service approach?
In a nutshell, are there unforseen and insurmountable problems that make approach #1 unworkable and if so are there any good third-party services we should look into for approach #2?