在ASP.NET中使用線程是否存在任何非明顯的危險？

這是this programmers question的兄弟問題。在ASP.NET中使用線程是否存在任何非明顯的危險？

簡而言之，我們正在考慮推出一些支持用戶請求的工作，將其「正確地」推送到後臺。如果我們走這條服務路線，這個相關問題給了我很多想法，但並沒有真正提供任何令人信服的論據來解釋爲什麼，我們應該如此。

我承認，對我來說，能夠做的

WorkQueue.Push(delegate(object context) { ... });

道德相當於是真的令人信服的，所以如果它只是一個有點困難（而不是固有不可行），我傾向於去與後臺線程方法。

因此，與後臺線程我知道的問題（在應用程序池的情況下）：

他們可以在任何時候因模具程序池被回收
- 解決方案：跟蹤正在執行任務時，因此它可以重新運行*應需要
的ThreadPool一個新的線程來傳入的HTTP響應查詢，因此使用它可以餓死IIS
- 解決方案：構建我們自己的線程池，並限制線程數量。

我的問題是，我缺少什麼，如果有什麼？ ASP.NET中的後臺線程還有什麼問題？

_{*問題中的任務已經安全地重新運行，所以這不是問題。}
_{ǂ假設我們沒有做任何愚蠢的事情，比如在後臺線程中拋出異常。}

來源

2010-10-22 Kevin Montrose

是不是線程的大多數'危險'非明顯？ – 2010-10-22 05:15:33

@Mitch - 我正在尋找那些ASP.NET特有的。那些行人的危險現在可以忽略不計，:) – 2010-10-22 05:16:54

我遇到的一個危險是CallContext。我們使用CallContext來設置用戶身份數據，因爲在我們的Web應用程序和基於.NET Remoting的應用程序服務（它旨在使用CallContext來存儲特定於通話的數據）中共享相同的代碼 - 所以我們沒有使用HttpContext。

我們注意到，有時候，一個新的請求會以CallContext中的非空身份結束。換句話說，ASP .NET不會將存儲在請求之間的CallContext中的數據置空......因此，如果未認證的用戶拿起仍具有包含經過驗證的用戶身份信息的CallContext的線程，則可能會進入該應用程序。

來源

2010-10-22 05:29:45 Jeff

讓我告訴你關於我使用的線程收集更新非明顯的危險:)

一些RSS源到我的數據庫的一個網站，我與GoDaddy主辦。線程工作正常（如果它們被終止，它們會由於我在一些網頁中建立的一些檢查而自動重啓）。

它工作得很好，我非常高興，直到GoDaddy（我的主人）首先開始殺死線程，然後完全阻止它們。所以我的應用程序剛死了！

如果那不是非顯而易見的，那是什麼？

來源

2010-10-22 05:42:21

有人可能是你過分複雜化你的架構沒有得到任何好處。

您的程序編寫起來會更昂貴，維護成本更高，並且更容易出現錯誤。

來源

2010-10-22 05:53:46

呃，我願意假設我們可以把它做好，如果它能夠正確地擺在首位。它不像我之前從未寫過線程池，Sam甚至在[mediabrowser]（http://code.google.com/p/videobrowser/）上有一個OSS'd（儘管它沒有IIS準備好，並且不兼容許可）。此外，還有其他好處：簡單性（不必跨越流程邊界進行編組）就是其中之一。 – 2010-10-22 05:58:14

是的，我相信你可以讓它工作，但額外的功能是否證明額外的工作和複雜性是正確的 – 2010-10-22 07:24:27

我會遠離啓動從你的IIS AppDomain的StackOverflow的線程。我沒有任何確鑿的證據支持我將要說的話，但與IIS合作了10年，我知道它在城鎮裏唯一的遊戲中效果最好。

還有一個替代方案，我知道這將在程序員線程上排序爲take off on my answer。但據我所知，你已經有了一個解決方案，可以在用戶請求上支持工作。爲什麼不使用該代碼，但只有在調用特殊的內部API時才啓動它。然後使用Task Scheduler調用一個CURL命令，每隔30秒調用一次該API來啓動任務。這樣您就可以讓IIS處理線程，並且您的代碼正在處理它已經很輕鬆的事情。

來源

2010-10-22 11:38:58

在ASP.NET中使用線程是否存在任何非明顯的危險？

回答

相關問題