2
我工作的地方在ASP.NET的HttpHandler運行其自己的線程池，它加載自己的進程外的COM對象的實例的遺留應用程序。請求進入並將工作負載傳遞給這些COM對象，並在完成時返回結果。ASP.NET處理程序，手動線程和COM服務器
處理工作正常，你肯定看到了池正在工作，同時請求進來可靠地處理......只要池中的線程數保持在10和游泳池不繁忙的請求飽和。一旦池既沒有飽和COM請求，也沒有純ASP.NETHandler請求再次觸發ASP.NET管道，直到池釋放一個實例。
當我運行16個實例線程池，並與長期運行需要5秒鐘即可完成（等待）請求命中服務器，我可以清楚地看到10個實例得到加載了工作。除此之外的任何實例都不會被擊中。不僅如此，即使直接的處理程序請求不會觸及COM池也會在此時開始排隊。
更多信息：
- COM池與MTA線程（STA，但不會改變任何東西）
- COM對象創建的STA線程和進程外的EXE的
- COM對象上執行（即沒有COM線程編組）
- ASP.NET線程發信號通知池線程開始處理
- 當前ASP.NET上下文被傳遞給池t hread
- 在Windows 10上運行.NET 4.5
- 測試臨
我使用自定義線程池的原因是因爲COM依賴性和需要，以保證COM對象保持在相同的線程加載沒有COM編組。如前所述，它可以正常工作，直到所有實例都處於繁忙狀態，然後纔會停止，直到池釋放新實例。
我可以理解的是，COM對象可能會被阻止，但我真的不明白爲什麼主線程ASP.NET會失敗，即使加工原料處理請求（即我有一個運行一個普通的響應標誌.Write（）響應和返回，它就像COM請求時池和飽和一樣等待和等待）
我懷疑它與COM對象實例化有關，但我很困惑爲什麼會出現這種情況對象是在非ASP託管線程上創建的。
有人看到的行爲像這樣的地方ASP.NET根本不會創造新的請求的線程，簡單地排隊？
是的 - 只是去和傾倒的處理程序到直播服務器，並能證實它工作得很好那裏與COM的實例加載了與原處理程序後立即開火。唷 - 我以爲我瘋了。 –
當然，希望他們至少在對本地主機IP進行測試時會刪除這些限制。這使得在本地機器上開發負載方案非常困難，除非您在服務器操作系統上進行開發:-( –