: StateServer करने के लिए सेट साइटें जब वेब गार्डन में inproc पर वापस लौटने

Question

परिदृश्य:

एक सर्वर .NET 3.0 चल रहा है और एक ASP.NET वेब साइट एक आवेदन पूल वेब है कि में चल ले लो बगीचे सक्षम (प्रक्रियाओं की संख्या: 3)।

 
    <sessionState 
     cookieless="UseCookies" 
     cookieName=".authz" 
     mode="StateServer" 
     regenerateExpiredSessionId="true" 
     stateConnectionString="tcpip=127.0.0.1:42424" 
     timeout="60" 
     useHostingIdentity="true" /> 

अब .NET 3.5 SP1 के लिए मशीन का उन्नयन: web.config विन्यास इस प्रकार है। सर्वर रीबूट करें। परिणाम: w3wp.exe के उदाहरणों में सत्रों को अब बनाए रखा नहीं जाता है, जैसे कि सभी इनप्रोक में वापस आ गए हैं। 1 कार्यकर्ता प्रक्रिया को कम करना वर्तमान कार्यवाही है।

क्या अजीब बात है: अलग सर्वर पर एक ही कोड कोई समस्या अनुभव करता है। मैंने पहले इस समस्या का अनुभव किया है, लेकिन यह फिर से शुरू होने के बाद जादुई रूप से चला गया। मैंने पहले से ही एक बार फिर से शुरू किया, लेकिन अब तक कोई खुशी नहीं है।

दो सर्वरों के दो machine.configs और web.configs की तुलना करना: समान।

Someone else has experienced this problem, लेकिन वहां कोई जवाब नहीं है।

कोई भी विचार? मैं वास्तव में इस पर स्टम्प्ड हूँ।

Answer 1

तो, यह एक अद्भुत था।

समस्या हो गया लगता है जब निम्न सभी शर्तें सत्य हैं:

• आप विंडोज सर्वर 2003 (IIS 6.0) और एक ASP.NET 2.0 वेब साइट चल रहे हैं।
• वेबसाइट वेब गार्डन का उपयोग करने के लिए कॉन्फ़िगर किया गया है, जहां अधिकतम कार्यकर्ता प्रक्रियाओं की संख्या 1 से अधिक है। इस वजह से, आपने अपने एप्लिकेशन को आउट-ऑफ-प्रोसेस सत्र संग्रहण का उपयोग करने के लिए कॉन्फ़िगर किया है; इस परिदृश्य में, एएसपी.NET राज्य सेवा स्थानीय मशीन पर चल रही है।
• एप्लिकेशन पूल पहचान नेटवर्क्स सेवा पर सेट नहीं है, लेकिन एक कस्टम, कम-विशेषाधिकार प्राप्त उपयोगकर्ता खाते जिसे आपने deployment best practice पर बनाया है।
• आप एक इंस्टॉलर जो .NET ढांचे को अद्यतन करता चलाने; मेरे मामले में, यह .NET 3.0 से .NET 3.5 SP1 का एक अद्यतन था।

उन्नयन खत्म और आप सर्वर रिबूट है, तो आप पाते हैं कि आपके सत्र चर अक्सर, एक पृष्ठ को ताज़ा करने पर खो रहे हैं के बाद से वहाँ आप की संभावना को केवल एक 3 में 1 मूल कार्यकर्ता प्रक्रिया है कि अपने मूल कार्य किया हो रही है निवेदन। लेकिन इससे कोई फर्क नहीं पड़ता, क्योंकि आप एएसपी.नेट राज्य सेवा का उपयोग कर रहे हैं। क्या टूट गया?

एएसपी.NET राज्य सेवा का उपयोग करते समय, एएसपी.नेट machineKey नामक मान का उपयोग करता है जिसे सभी सत्र डेटा को एन्क्रिप्ट करने और/या हैश को संग्रहीत करने के लिए उपयोग किया जाता है (मुझे नहीं पता कि यह एन्क्रिप्टिंग या हैशिंग या दोनों है, लेकिन यह है इस चर्चा के लिए एक महत्वपूर्ण भेद नहीं)। यह इतना है कि जब किसी भी वर्कर प्रोसेस एक सत्र पहचानकर्ता का उपयोग करके सेवा से डेटा के लिए पूछता है, यह सुनिश्चित करें कि डेटा, जबकि यह बाहरी डेटा स्रोत में संग्रहीत किया जा रहा था के साथ छेड़छाड़ नहीं की गई थी हो सकता है।

यदि आप वेब फार्म पर हैं, तो संभवतः आपके पास फ़ाइल में परिभाषित एक स्थिर machineKey है, और यह समस्या नहीं होती है। लेकिन एक एकल सर्वर वेब उद्यान परिदृश्य के लिए, तो आप शायद डिफ़ॉल्ट machineKey सेटिंग है, जो ASP.NET 2.0 अनुप्रयोगों के लिए AutoGenerate,IsolateApps के लिए निर्धारित है पर निर्भर हैं। इसका मतलब है कि एएसपी.नेट स्वचालित रूप से एक मशीन कुंजी उत्पन्न करता है जो आपके एप्लिकेशन पूल के लिए अद्वितीय है।यह कुछ एल्गोरिदम के अनुसार इस कुंजी को पुन: उत्पन्न करता है, लेकिन यह चर्चा के लिए यह महत्वपूर्ण नहीं है।

उत्पन्न मूल्य आमतौर पर रजिस्ट्री में HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity} के अंतर्गत संग्रहीत किया जाता है। लेकिन .NET Framework इंस्टॉलर गलत तरीके से (मुझे विश्वास है कि यह एक बग है) इस रजिस्ट्री कुंजी को नष्ट कर देता है और, चोट के अपमान को जोड़ने के लिए, इस कुंजी पर अनुमतियां रीसेट करता है जैसे कि आपकी कस्टम एप्लिकेशन पूल पहचान रजिस्ट्री प्रविष्टि को लिखने पर लिख नहीं सकती अपनी नई मशीन कुंजी बनाने के लिए।

परिणाम यह है कि वेब कार्यशाला में फैले प्रत्येक कार्यकर्ता की प्रक्रिया मशीन की कुंजी की अपनी इन-मेमोरी प्रति का उपयोग कर रही है, जो कि समय पर उत्पन्न होती है, जो प्रभावी रूप से दुर्घटना से वेब फार्म परिदृश्य बनाती है। उदाहरण के लिए, कार्यकर्ता प्रक्रिया एक स्पिन अप, देखती है कि AutoGenKey प्रविष्टि मौजूद है (वास्तव में, यह भी पढ़ नहीं सकती है), अपना स्वयं का उत्पादन करती है और एएसपी.NET राज्य सेवा को भेजे गए हैश डेटा का उपयोग शुरू करती है। यह रजिस्ट्री प्रविष्टि में इस नई मशीन कुंजी को सहेजने का प्रयास करता है, लेकिन चुपचाप विफल रहता है। वर्कर प्रक्रिया बी स्पिन अप, देखता है कि AutoGenKey प्रविष्टि मौजूद है, अपना खुद का उत्पादन करती है और का उपयोग शुरू करती है जो हैश डेटा में ... आप देखते हैं कि यह कहां जा रहा है।

परिणाम अब आपके पास तीन अलग-अलग मशीन कुंजियों के साथ सत्र डेटा है। हालांकि सत्र पहचानकर्ता के लिए डेटा मौजूद है, फिर भी तीन कार्यकर्ता प्रक्रियाओं में से दो इसे अमान्य/छेड़छाड़ के रूप में अस्वीकार कर देंगे क्योंकि यह अपनी कुंजी का उपयोग कर रही है।

आप अपने web.config फ़ाइल में स्पष्ट रूप से कस्टम machineKey सेट करके इसे प्राप्त कर सकते हैं।

या आप टूटी अनुमतियों को ठीक करने के लिए कमांड प्रॉम्प्ट पर aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName को फिर से चला सकते हैं।

आपकी समस्या हल हो गई है। बिस्तर पर जाने का व़क्त।

---

अद्यतन जून 30 वीं:Microsoft Connect पर इस मुद्दे का मेरी रिपोर्ट के अनुसार, माइक्रोसॉफ्ट ने संकेत दिया है कि वे संस्थापक तय कर दी है इस तरह के इस व्यवहार उन्नयन के साथ शुरुआत 4. यह अभी भी कर सकते थे नेट के लिए नहीं होगा कि भविष्य के 3.0/3.5 उन्नयन के लिए होता है, इसलिए मैं इस प्रश्न/उत्तर को खड़ा कर दूंगा।