在生產環境中,我有一個IIS託管的asp.net應用程序,實際上是許多Web應用程序。每個應用程序消耗大量內存,但目前限制它的唯一方法是回收(nHibernate似乎在泄漏內存,並且它創建了大量的字符串集合)。問題在於,在回收之後,它會不斷登錄用戶或者放棄會話?在本地計算機上,我無法重新創建問題。我已經嘗試過使用狀態服務器沒有運氣,問題不斷,SQL狀態保存chane任何東西,或者我只是想念含鉛或缺少的東西?註銷回收
註銷回收
回答
答案是令人驚訝和它來查看我在我的應用登錄狀態的錯誤有關,我找到了適當的解釋上MSDN sites之一,此行特別是:
有關的machineKey
「[...]當應用程序池在用戶帳戶下運行時,上述密鑰不會生成,導致間歇性無效視圖狀態錯誤。
總而言之,所有必須做的事情是generating a machine key,並且回收不會導致用戶重新進行身份驗證。
當應用程序池被回收時,如果會話數據存儲在內存中(InProc,默認),所有會話都會丟失。
通過在用戶的瀏覽器中放置一個帶有密鑰的cookie並將該密鑰保存在服務器狀態機上來創建會話。
如果您使用SQL Server存儲會話,您將避免服務器丟失會話信息。 Session-State modes on MSDN。
你寫了你嘗試過StateServer模式,但stateserver模式像sqlserver一樣工作如果我不知道它錯了。 StateServer可以從Windows服務啓動,並且可以在您的web.config中設置您的服務器IP地址(哪個狀態服務器已啓動並正在工作)。
如果狀態服務器不能爲你工作,我懷疑sql服務器會。問題可能出現在我感覺到的另一個領域。
ASP.NET會話狀態支持 會話數據的幾個不同的存儲選項。每個選項都由 SessionStateMode枚舉中的值標識。下面的列表介紹了 可用的會話狀態模式:
是InProc模式,存儲在Web服務器上存儲會話狀態。 這是默認設置。
StateServer模式,它在單獨的進程 中存儲會話狀態,稱爲ASP.NET狀態服務。這確保瞭如果Web應用程序重新啓動,也使得Web場中提供給多個Web服務器會話 狀態會話狀態 保留。在SQL Server數據庫
SQLServer的模式存儲會話狀態。 確保會話狀態保留,如果Web應用程序是 重新啓動並且還使Web會話中的多個Web 服務器可用的會話狀態。
自定義模式,使您可以指定自定義存儲提供程序。
關閉模式,禁用會話狀態。
您可以指定要ASP.NET會話狀態由 分配SessionStateMode枚舉值的模式使用的模式屬性在應用程序的Web.config文件中sessionState元素的 。比是InProc和關閉其它 模式需要額外的參數,如 連接字符串值如本主題後面討論。通過訪問HttpSessionState.Mode屬性的值 ,您可以 查看當前選定的會話狀態。
- 1. 註銷廣播接收器
- 2. 註銷後收到通知
- 3. 註銷並返回按鈕
- 4. 註銷後GCM仍然收到通知
- 5. NullpointerException註銷廣播接收器
- 6. 註銷接收器清單XML文件
- 7. 強制註銷付款收據頁面
- 8. 註銷廣播接收機表現
- 9. 完成()註銷廣播接收器嗎?
- 10. 註銷的ViewModels在註銷
- 11. Android註銷接收器,但仍然收到
- 12. Android:從小部件註冊和註銷廣播接收器(ACTION_TIME_CLICK)
- 13. Android廣播接收器註冊清單時需要註銷嗎?
- 14. 註冊/註銷啓動廣播接收機
- 15. 廣播接收器註冊和註銷未在Android的
- 16. 註銷
- 17. 註銷似乎並未真正註銷
- 18. 註銷JS SDK不會註銷PHP SDK
- 19. 註銷Django當前時區註銷後
- 20. Activeadmin不註銷,當我點擊「註銷」
- 21. Orchard CMS:註銷(註銷)確認頁面
- 22. Firebase/Facebook - 如何註銷/註銷?
- 23. 從WireCloud註銷不會從KeyStone註銷
- 24. 流失註銷舊會話註銷
- 25. 同步Apache註銷與Django註銷
- 26. 註銷時註銷所有活動
- 27. Thinktecture隱式流:註銷/註銷用戶
- 28. 檢索註銷時間而不註銷
- 29. IBM Bluemix AppID - 如何註銷/註銷?
- 30. 註銷後防止返回頁面
我們在大型應用程序中遇到了這個問題。回收工作進程確實會導致連接的會話失去身份驗證,並且我們正在使用狀態服務器和負載平衡粘滯會話。我們確信,只能使用IE6和32位IIS6,而改變任何一項都會改善問題。看到你使用IIS7時出現同樣的問題令人失望,並且我得出結論:SQLServer會話數據庫可能是解決這個問題的唯一方法。但是:您使用的是32位還是64位服務器? – 2012-04-22 13:23:24
非常有趣的安德魯!我在64位上運行它,並且在某些時候我嘗試了一個微軟MVP的建議,迫使工作進程在32位運行,但最初的結果是,最終有希望是災難性的。進程崩潰隨機丟失所有數據並混淆了我們的數據庫(實際上是由於崩潰導致的ORM故障) – Jacob 2012-04-22 14:33:46