2012-12-27 8 views
6

मेरे पास मेरे ऐप में django सत्रों के साथ एक अजीब बग है: कुछ बार (20000 प्रति दिन 20000 प्रति दिन) उपयोगकर्ता के लिए सत्र जानकारी मिटा दी जाती है। मैंने लॉग फाइलों के माध्यम से इसका पता लगाया: पृष्ठ ए पर उपयोगकर्ता के सत्र के लिए जानकारी है, उसके बाद वह फॉर्म सबमिट करता है और अगले पृष्ठ पर उसका सत्र खाली होता है। मैंने दो प्रकार के भंडारण की कोशिश की: memcached + डीबी और डीबी केवल और यह समस्या दोनों के लिए है। मैंने इन परिदृश्यों को पुन: पेश करने की कोशिश की, लेकिन जैसा कि मैंने कहा, सभी काम अपेक्षित हैं, यह बहुत दुर्लभ होता है। मैंने यह भी जांच की कि यह समस्या विभिन्न उपयोगकर्ताओं के लिए मौजूद है, और उनके लिए हर बार पुन: उत्पन्न नहीं होती है। मेरे पास मूल कारणों को पकड़ने के बारे में कोई विचार नहीं है और मुझे नहीं पता कि विवरण के रूप में यहां और क्या पोस्ट किया गया है। अगर किसी के पास कोई विचार है, तो कृपया मुझे बताएं। यदि यह महत्वपूर्ण है, तो मैं अपने एप को डीजेंगो 1.2 + फास्टसीजीआई के साथ चला रहा हूं। धन्यवाद!django सत्रों के साथ ट्रिकी समस्या: कभी-कभी सत्र की जानकारी मिटा दी जाती है

यूपीडी: मैंने जांच की है कि उपयोग से उस सत्र कुंजी को दो अनुक्रमिक अनुरोधों के दौरान बदला नहीं जाता है, पहले अनुरोध पर एक वास्तविक सत्र स्थिति होती है, और दूसरे सत्र चर में खाली से जुड़े होते हैं।

+0

क्या आप किसी भी जावास्क्रिप्ट का उपयोग करते हैं जो एक समवर्ती अनुरोधों को जन्म दे सकता है ताकि दोनों सत्र को संशोधित कर सकें? – hynekcer

+0

@hynekcer, जेएस से कॉल में कोई सत्र अपडेट नहीं किया गया है। – dbf

+0

क्या आप वाकई फास्टसीजीआई में मल्टीथ्रेडिंग का उपयोग नहीं करते हैं? (यदि आप FCGI_MAX_CONNS = 1, FCGI_MAX_REQS = 1, FCGI_MPXS_CONNS = 0 सेट करते हैं, तो आप केवल एक थ्रेड का उपयोग करना सुनिश्चित कर सकते हैं, जो आपके द्वारा उपयोग किए जाने वाले फास्टसीजी कार्यान्वयन पर अनिश्चित है: [फास्टसीजीआई विनिर्देश] (http://www.fastcgi.com/drupal/नोड/6? क्यू = नोड/22)) तो मैं यह देखने के लिए प्रक्रिया आईडी के लॉगिंग की अनुशंसा करता हूं कि इसे केवल उसी प्रक्रिया द्वारा मिटाया जा सकता है या केवल एक अलग प्रक्रिया द्वारा। (लॉगिंग प्रारूप स्ट्रिंग या "os.getpid()" फ़ंक्शन में "% (प्रक्रिया) डी" का उपयोग करें।) – hynekcer

उत्तर

4

एक तरह से इस समस्या को डिबग करने के लिए के रूप में, मैं मानक Django सत्र मिडलवेयर उपवर्ग हैं (या जो भी आप वर्तमान में उपयोग कर रहे हैं): (शायद अधिक महत्वपूर्ण बात)

django.contrib.sessions.middleware.SessionMiddleware

और रैप process_request और process_response में कुछ अतिरिक्त लॉगिंग। फिर Django एक स्टॉक के बजाय MIDDLEWARE_CLASSES में अपने उप-वर्गीकृत सत्र मिडलवेयर को इंस्टॉल करें।

आप यह भी सत्यापित कर सकते हैं कि session.save() वास्तव में इसे वापस पढ़ने का प्रयास करके अपने परिवर्तन किए हैं। यह हो सकता है कि समस्या सत्र-राज्य क्रमिकरण में निहित है, और यह उस विशेष कुंजी या मूल्य पर असफल रहा है जिसे आप स्टोर करने का प्रयास कर रहे हैं।

इनमें से कोई भी आपकी समस्या को ठीक नहीं करेगा, लेकिन यह आपको यह निर्धारित करने में मदद कर सकता है कि क्या हो रहा है।

4

जैसा कि @ स्टेव मायेन ने उल्लेख किया है, सत्र मध्यवर्ती और सत्र मॉडल सहेजने के तरीके पर कुछ लॉगिंग करना अच्छा होगा। यह कुछ है जिसके साथ मैं शुरू करूंगा।

इसके अलावा मैं यह कहना चाहूंगा कि यह डेटाबेस से संबंधित समस्या हो सकती है, खासकर यदि आप सत्रों के लिए MySQL डेटाबेस बैकएंड का उपयोग कर रहे हैं। आप डेटाबेस ताले और अन्य समवर्ती मुद्दों के लिए लॉग की जांच कर सकते हैं। मुझे पहले इसी तरह के मुद्दों से निपटना पड़ा और समाधान स्पष्ट है: अनुकूलन और अतिरिक्त प्रदर्शन।

यदि आपके पास कुछ विशिष्ट एप्लिकेशन मिडलवेयर है, तो आप Django सत्रों में हस्तक्षेप करने वाली कार्यक्षमता की जांच कर सकते हैं। इस तरह के समानांतर संचालन समस्याओं का कारण बन सकते हैं, अगर सही ढंग से लागू नहीं किया गया है।

एक और चीज जो मैं करता हूं वह है Django की नवीनतम स्थिर रिलीज में अपग्रेड करना और mod_wsgi सेटअप में माइग्रेट करना।