我們看到,在加載情況下會話數據被破壞或丟失,但會話本身仍然存在。ASP.NET會話已損壞加載
我們的網站託管在運行ASP.Net 4.0的IIS 7上,並且在Web服務器場中使用InProc會話狀態,並在Cisco ACE Appliance負載均衡器後面共有4臺服務器。
此時問題是隨機的,我們不能隨意重現問題。這個網絡應用程序在過去七個月裏一直運行正常。
我們認識到,即使正在使用粘性會話,Microsoft也不建議將InProc與Web場一起使用。
我們確實有一個實驗室環境,與我們的生產環境合理相同,但無法在實質負載下重現(我們使用WAPT)。
在我們的生產環境中,我們試圖在負載平衡器後面隔離一個服務器,以消除負載平衡器本身造成的「服務器跳躍」。但是,即使在一臺服務器上運行,問題仍然存在。我們在生產中看不到任何AppPool或IIS回收。作爲標準做法,我們每天在美國東部時間凌晨3點回收生產應用程序池,並且在操作系統上享有數月的正常運行時間。
會話中存儲的內容包括從簡單類型(整數和字符串)到整個購物車(複雜對象圖)甚至用戶控件(.ascx)實例的各種對象。由於無法輕鬆對這些對象中的很多對象進行序列化,因此我們無法在合理的時間段內切換到進程外會話存儲。
有人建議嘗試使用Fiddler捕獲HTTP會話。運行Fiddler的問題是我們不能有意地自行重現問題。所以,這使我們無法捕獲發生故障事件的HTTP跟蹤。我們實驗室的WAPT跟蹤記錄可能會提供與Fiddler相同的數據,但正如我所說的,我們不能在那裏複製它。
我會非常感謝任何見解的人可能有...基於所有的迄今這裏收集的信息
你有關於哪個會話數據被破壞的信息嗎?它是購物車嗎?它是隨機的嗎?你怎麼知道你是否無法重現它?而且,我確信你之前聽說過這個,所以我可能聽起來像是一個破損的記錄,你可能想要做一些關於需要在會話中存儲用戶購物車的整個對象圖並存儲用戶控制實例。 – Sumo
我們知道即使我們無法複製它,因爲我們收到帶有堆棧跟蹤的電子郵件時發生,與客戶呼叫巧合。它通常是隨機值,但特別是似乎正在丟棄,它來自包含訪問此會話變量的共享只讀屬性。這是非常隨機的,但肯定發生在負載下,因爲我的客戶服務人員直到應用程序池啓動後經過一段時間纔開始接受投訴。是的,我們知道我們需要將該淫穢對象圖和用戶控制權排除在會話之外,但該修復程序距離幾周。 :/ –
你能發佈關於這個共享變量的更多細節嗎? – Sumo