Interesting experience with Community Server background tasks today. In my CS-based Jobs Management Application I have a number of background tasks running all the time, one of which is a data import task that pulls in data from a number of Access databases. There's a description and screenpic on this post.
This task normally takes only a few seconds to execute, but mid-morning the task began taking over 3 minutes! Without the background task monitoring I added to this process I never would have known there was a problem. The mysterious thing was that only the Production site was affected. Staging, running on the same server, was executing normally. I even grabbed a copy of the production SQL database and loaded it on my home office network. That ran beautifully, too. Bafflement!
What was unique about that goofy Production database and website, anyway? I then considered the nature of Community Server background tasks, that they are inextricably intertwined with the site's Application Pool. If the app pool is corrupt, bad things happen with Community Server background tasks. The Wizard taught me that.
Oooo-boy, the Production and Staging sites on the server were indeed using different application pools. There was hope.
Then, after I created a new app pool and assigned the Production Site to it, there was jubilation. The import background tasks were back to taking 3 seconds to execute. When the quiet calm of everyday Community Server coding returned, I appreciated this fine lesson. Sometimes you need a fresh app pool.