104, 'सहकर्मी सॉकेट त्रुटि द्वारा कनेक्शन रीसेट, या जब एफआईएन के बजाय आरएसटी में सॉकेट परिणाम बंद करता है?

Question

हम समानांतर में एक पायथन वेब सेवा और क्लाइंट वेबसाइट विकसित कर रहे हैं। जब हम सेवा करने के लिए ग्राहक से एक HTTP अनुरोध बनाने के लिए, एक कॉल लगातार socket.py में एक socket.error, पढ़ने में जन्म देती है:

(104, 'Connection reset by peer')

जब मैं wireshark साथ में सुनने के लिए, "अच्छा" और "बुरा "प्रतिक्रियाएं बहुत समान दिखती हैं:

• ओएथ हेडर के आकार के कारण, अनुरोध दो पैकेट में विभाजित है। सेवा एसीके
• दोनों के साथ प्रतिक्रिया देती है, सेवा प्रतिक्रिया भेजती है, प्रति हेडर एक पैकेट (HTTP/1.0 200 ठीक है, फिर दिनांक शीर्षलेख इत्यादि)। ग्राहक एसीके के साथ प्रत्येक को जवाब देता है।
• (अच्छा अनुरोध) सर्वर एक एफआईएन, एसीके भेजता है। ग्राहक एक एफआईएन, एसीके के साथ जवाब देता है। सर्वर एसीके का जवाब देता है।
• (खराब अनुरोध) सर्वर एक आरएसटी, एसीके भेजता है, क्लाइंट एक टीसीपी प्रतिक्रिया नहीं भेजता है, सॉकेट। ग्राहक पक्ष पर आतंक उठाया जाता है।

दोनों वेब सेवा और क्लाइंट एक जेनेटू लिनक्स x86-64 बॉक्स पर चल रहे हैं glibc-2.6.1 चल रहे हैं। हम उसी वर्चुअल_एनवी के अंदर पाइथन 2.5.2 का उपयोग कर रहे हैं।

क्लाइंट एक Django 1.0.2 ऐप है जो अनुरोध करने के लिए httplib2 0.4.0 को कॉल कर रहा है। हम OAuth हस्ताक्षर एल्गोरिदम के साथ अनुरोधों पर हस्ताक्षर कर रहे हैं, OAuth टोकन हमेशा खाली स्ट्रिंग पर सेट होता है।

सेवा WERKZEUG 0.3.1, जो पायथन के wsgiref.simple_server उपयोग कर रहा है चल रहा है। मैं wgsiref.validator के माध्यम से WSGI ऐप चलाया बिना किसी समस्या के।

ऐसा लगता है कि यह डीबग करना आसान होना चाहिए, लेकिन जब मैं सेवा पक्ष पर एक अच्छे अनुरोध के माध्यम से पता लगाता हूं, तो यह socket._socketobject.close() फ़ंक्शन में, खराब अनुरोध की तरह दिखता है, प्रतिनिधि तरीकों को बदलता है डमी विधियों। जब प्रेषण या प्रेषण (जिसे याद नहीं किया जा सकता) विधि बंद कर दी जाती है, तो एफआईएन या आरएसटी भेजा जाता है, और ग्राहक प्रसंस्करण शुरू कर देता है।

"सहकर्मी से कनेक्शन रीसेट" सेवा पर दोष जगह करने लगता है, लेकिन मैं या तो httplib2 पर भरोसा नहीं करते। क्या ग्राहक गलती हो सकता है?

** इसके अलावा डिबगिंग - लिनक्स पर सर्वर **

मैं एक मैकबुक है की तरह लग रहा है, इसलिए मैं एक पर सेवा और अन्य पर ग्राहक वेबसाइट चला की कोशिश की। लिनक्स क्लाइंट बग के बिना ओएस एक्स सर्वर को कॉल करता है (एफआईएन एसीके)। ओएस एक्स क्लाइंट लिनक्स सेवा को बग (आरएसटी एसीके, और ए (54, 'पीयर द्वारा कनेक्शन रीसेट') के साथ कॉल करता है)। तो, ऐसा लगता है कि यह लिनक्स पर चल रही सेवा है। क्या यह x86_64 है? एक बुरा glibc? wsgiref? फिर भी देख ...

** इसके अलावा परीक्षण - wsgiref परतदार **

हम अपाचे और mod_wsgi के साथ उत्पादन करने के लिए चले गए हैं लग रहा है, और कनेक्शन फिर सेट करता है चले गए हैं। नीचे मेरा जवाब देखें, लेकिन मेरी सलाह है कि कनेक्शन रीसेट लॉग करें और पुनः प्रयास करें। इससे आपके सर्वर को विकास मोड में और उत्पादन में दृढ़ता से चलने दिया जाएगा।

Answer 1

मुझे यह समस्या है। The Python "Connection Reset By Peer" Problem देखें।

आप (सबसे अधिक संभावना) अजगर वैश्विक दुभाषिया लॉक के आधार पर छोटे समय के मुद्दों के afoul चलाने की है।

आप इसे कभी-कभी time.sleep(0.01) के साथ रणनीतिक रूप से स्थापित कर सकते हैं।

"कहां?" तुम पूछो। मुझे पता नहीं। विचार क्लाइंट अनुरोधों के आस-पास और आसपास कुछ बेहतर थ्रेड समेकन प्रदान करना है। इसे से पहले डालने का प्रयास करें, आप अनुरोध करते हैं ताकि जीआईएल रीसेट हो और पाइथन दुभाषिया किसी भी लंबित धागे को साफ़ कर सके।

Answer 2

आम तौर पर, यदि आप एक करीबी काम करते हैं तो आप एक आरएसटी प्राप्त करेंगे (यानी अगर डेटा को स्टैक द्वारा छोड़ा जा सकता है यदि उसे भेजा नहीं गया है और ACK'd किया गया है) और सामान्य एफआईएन आप करीब रहने की अनुमति देते हैं (यानी बंद एसीकेड होने के लिए पारगमन में डेटा के लिए प्रतीक्षा करता है)।

शायद आपको बस इतना करना है कि आप अपनी सॉकेट को अदरक पर सेट कर दें ताकि आप सॉकेट पर किए गए गैर-करीब बंद होने और एसीके पहुंचने के बीच दौड़ की स्थिति को हटा दें?

Answer 3

उत्पादन के लिए wsgiref का उपयोग न करें। अपाचे और mod_wsgi, या कुछ और का प्रयोग करें।

हम इन कनेक्शन रीसेट को कभी-कभी देखते हैं, कभी-कभी, wsgiref (werkzeug test server द्वारा उपयोग किए जाने वाले बैकएंड, और संभवतः Django परीक्षण सर्वर जैसे अन्य) के साथ। हमारा समाधान त्रुटि लॉग करना था, एक लूप में कॉल को पुनः प्रयास करना था, और दस विफलताओं के बाद छोड़ देना था। httplib2 दो बार कोशिश करता है, लेकिन हमें कुछ और चाहिए। वे बंच में भी आते हैं - एक दूसरी नींद जोड़ना इस मुद्दे को साफ़ कर सकता है।

अपाचे और mod_wsgi के माध्यम से चलते समय हमने कभी कनेक्शन रीसेट नहीं देखा है। मुझे नहीं पता कि वे अलग-अलग क्या करते हैं, (शायद वे सिर्फ उन्हें मुखौटा करते हैं), लेकिन वे प्रकट नहीं होते हैं।

जब हमने स्थानीय देव समुदाय से मदद के लिए पूछा, तो किसी ने पुष्टि की कि वे उत्पादन सर्वर पर जाने वाले wsgiref के साथ बहुत से कनेक्शन रीसेट देख रहे हैं। वहां एक बग है, लेकिन इसे ढूंढना मुश्किल होगा।

Answer 4

मुझे एहसास है कि आप पाइथन का उपयोग कर रहे हैं, लेकिन मुझे यह जावा आलेख उपयोगी साबित हुआ। क्यों सर्वर आरएसटी reques भेज

http://java.sun.com/javase/6/docs/technotes/guides/net/articles/connection_release.html