【发布时间】：2016-06-07 12:28:24
【问题描述】：
我正在开发一个遗留应用程序，其中 ASP.NET HttpHandler 正在运行自己的线程池，该线程池加载自己的进程外 COM 对象实例。请求进来并将工作负载传递给这些 COM 对象，完成后返回结果。
处理工作正常，您肯定会看到池正在工作，因为同时进来的请求得到可靠处理......只要池线程数保持在 10 以下并且池没有被繁忙的请求饱和。一旦池中的 COM 请求和普通的 ASP.NET 处理程序请求都不再到达 ASP.NET 管道，直到池释放一个实例。
当我使用 16 个实例运行线程池并通过长时间运行（等待）请求（需要 5 秒才能完成）访问服务器时，我可以看到正好有 10 个实例加载了工作。除此之外的任何实例都不会被击中。不仅如此——即使是没有命中 COM 池的直接处理程序请求也会在此时开始排队。
更多信息：
- COM 池是使用 MTA 线程创建的（但 STA 不会更改任何内容）
- COM 对象是 STA 线程和进程外 EXE
- COM 对象在创建它们的同一固定线程上执行（即没有 COM 线程编组）
- ASP.NET 线程向池线程发出信号以开始处理
- 当前 ASP.NET 上下文被传递到池线程
- 运行 .NET 4.5
- 在 Windows 10 专业版上测试
我使用自定义线程池的原因是因为 COM 依赖性以及需要确保 COM 对象在没有 COM 编组的情况下保持加载在同一个线程上。如前所述，它可以正常工作，直到所有实例都处于忙碌状态，然后一切才会停止，直到池释放新实例。
我可以理解 COM 对象可能被阻止，但我真的不明白为什么主 ASP.NET 线程甚至无法处理原始处理程序请求（即，我有一个运行普通响应的标志。 Write() 响应并返回，当池饱和时，它就像 COM 请求一样坐下来等待）
我怀疑它与 COM 对象实例化有关，但我很困惑为什么在非 ASP 托管线程上创建对象时会发生这种情况。
有没有人见过这样的行为，其中 ASP.NET 根本不会创建新的请求线程并只是排队？
【问题讨论】：
标签： asp.net multithreading com