对于一个控制器，新的线程创建默默地失败了，而对于另一个控制器却没有？ C＃ASP.NET（IIS 8.5）Web API 2

Question

I have two controllers set up in a Web API 2 project. The first controller starts n processing sessions by calling the other controller.

First controller in psuedo-code:

[HttpPost]
public bool Post(...)
{
 ...
 StartProcessingSessions(howMany)
}
void StartProcessingSessions(...)
{
 for (i=1 to HowMany)
  Task.Factory.StartNew(() => StartProcessingSession(...);
}
void StartProcessingSession(...)
{
 [post async to 2nd controller]
}

This code works just fine and the 2nd controller is called. The 2nd controller attempts to create a thread the exact same way to do some potentially long running work (1-10 minutes) but that thread fails to start, silently. After trawling the internet, I've read conflicting information about the support for creating threads within IIS. Most say that after 4.5.2 it should work no problem, but others say it has always worked. For corporate reasons, I can't go beyond 4.5.1 for the time being.

Best of all, the code works correctly in debug mode and only fails when deployed to the web server.

I have tried replacing the processing with a simple db log write, but it does not execute. Other methods of creating a thread fail silently as well. If I remove the thread creation in the 2nd controller, everything works correctly.

Next, I plan to try simplifications of the controllers to see if I can pinpoint what exactly is the criteria that blocks the thread.

Any insights? Thanks

Edit: here's a simple controller that can stand in as "Controller 2" that illustrates the problem. The first log is written and the second is not.

    [HttpPost]
    public bool Post()
    {
        _logRepository.InsertError("Modeling Debugging", "TestController hit");
        Task.Factory.StartNew(() => _logRepository.InsertError("Modeling Debugging", "TestController Thread"));
        return true;
    }

Answer 1

It appears this is just a "safety" limitation of ASP.NET, possibly intended to prevent the developer from potentially shooting self in foot via request splitting ballooning out of control. I haven't found any information that confirms this but it is the only plausible explanation I have at this point.

If you can use .NET 4.5.2+ it may be a moot point since you have the BackgroundWorker which might not be subject to this restriction. I'm not blocked in my use case above since I still was able to get the threads I wanted though I had run them directly as the controller thread. Not what I wanted, but it works to give me full CPU usage.