मेरे पास जावा पर वेबलॉगिक 11 जी में चल रहा जावा एप्लिकेशन है, जो कई दिनों के बाद, उत्तरदायी नहीं हो जाता है। एक संदेहजनक लक्षण मैंने देखा है कि सर्वर की निष्क्रिय होने पर भी CLOSE_WAIT स्थिति के साथ netstat
में बड़ी संख्या में कनेक्शन (लगभग 3000) दिखाई देते हैं। चूंकि एप्लिकेशन सर्वर क्लाइंट कनेक्शन का प्रबंधन कर रहा है, इसलिए मुझे यकीन नहीं है कि इसका क्या कारण है। हम कई वेब सेवा कॉल भी करते हैं जो एक ही सर्वर पर लूपबैक करते हैं, लेकिन मेरा मानना है कि वे कनेक्शन ठीक से बंद हो जाते हैं। इसका और क्या कारण हो सकता है और इस तरह की समस्या का निवारण कैसे करता है?CLOSE_WAIT स्थिति में फंस गए समस्या निवारण कनेक्शन
उत्तर
समस्या एक बग WebLogic में सच करने के लिए "का प्रयोग करें JSSE एसएसएल" सेटिंग से शुरू हो रहा था। जेएसएसई के बजाय वेबलॉगिक के अपने एसएसएल कार्यान्वयन का उपयोग करना हमारे आवेदन के लिए कोई समस्या नहीं है, इसलिए मैंने केवल उस सेटिंग को अनचेक कर दिया और समस्या गायब हो गई।
मैं CLOSE_WAIT pileups के बारे में इस उद्धरण मिला: "कुछ या तो को प्रगति को रोकने HTTP सत्र में होते है (हम फंस रहे हैं तो अंत कभी नहीं पास बुला), या कुछ बग शुरू किया गया है कि बंद किया जा रहा से सॉकेट से बचाता है ऐसा होने के कई तरीके हैं। "
सोचें: क्या कोई अनुरोध संसाधित करते समय आपका एप्लिकेशन अटक जा रहा है? या WebLogic खुद?
जांच: क्या आप जावा थ्रेड डंप कर सकते हैं (मारने के लिए सिग्क्विट का उपयोग ओरेकल जेवीएम पर लिनक्स के लिए किया जा सकता है) यह देखने के लिए कि वास्तव में आपके किसी भी थ्रेड फंस रहे हैं?
ग्राहक पक्ष की जांच करें: सबसे पहले, CLOSE_WAIT सॉकेट से जुड़े क्लाइंट के आईपी पते या होस्टनाम का पता लगाएं। फिर, देखें कि उन ग्राहकों पर कुछ भी संदिग्ध हो रहा है या नहीं।
CLOSE_WAIT
स्थिति का मतलब है कि दूसरी तरफ कनेक्शन बंद हो गया है, लेकिन स्थानीय पक्ष के आवेदन ने अभी तक सॉकेट बंद नहीं किया है।
ऐसा लगता है कि आपके स्थानीय एप्लिकेशन में एक बग है।
CLOSE_WAIT
राज्य स्थानीय टीसीपी राज्य मशीन है जब रिमोट होस्ट एक एफआईएन भेजता है (इसका कनेक्शन बंद करता है) लेकिन स्थानीय एप्लिकेशन ने ऐसा नहीं किया है और एक जवाब भेजा है। स्थानीय मशीन के लिए इस बिंदु पर डेटा भेजने के लिए अभी भी संभव है हालांकि क्लाइंट इसे प्राप्त नहीं कर सकता है (जब तक कि यह कनेक्शन पर केवल आधे बंद न हो)।
जब रिमोट होस्ट बंद हो जाता है (एक एफआईएन भेजता है), तो आपके स्थानीय एप्लिकेशन को कुछ प्रकार की घटना मिल जाएगी (यह बेस सी लाइब्रेरी में सॉकेट पर "पढ़ा" ईवेंट है) लेकिन उस कनेक्शन से पढ़ने से एक त्रुटि वापस आ जाएगी यह इंगित करने के लिए कि कनेक्शन बंद हो गया है। इस बिंदु पर स्थानीय आवेदन कनेक्शन बंद करना चाहिए।
मुझे जावा के बारे में कुछ पता नहीं है और वेबलॉगिक के बारे में कुछ भी नहीं है, लेकिन मुझे लगता है कि यह संभव है कि एप्लिकेशन पढ़ने की त्रुटि को ठीक से संभाल नहीं रहा है और इस प्रकार कनेक्शन को कभी बंद नहीं कर रहा है।
मुझे एक ही समस्या है और मैं इस मुद्दे से छुटकारा पाने के लिए सॉकेट का अध्ययन कर रहा हूं।
मुझे कुछ शब्द कहने दो, लेकिन इससे पहले कि मुझे कहना होगा कि मैं जावा प्रोग्रामर नहीं हूं।
मैं यह नहीं समझाऊंगा कि close_wait क्या है, क्योंकि ब्रायन व्हाइट ने पहले ही कहा था कि सब कुछ कहा जाना चाहिए।
close_wait से बचने के लिए, आपको यह सुनिश्चित करना होगा कि आपका सर्वर प्रतिक्रिया को वापस भेजने के बाद कनेक्शन बंद न करे क्योंकि जो भी पहले डिस्कनेक्ट हो जाता है, वह close_wait और time_wait में फंस जाता है। इसलिए, अगर आपका सर्वर close_wait में फंस रहा है तो यह मुझे बताता है कि प्रतिक्रिया भेजने के बाद यह डिस्कनेक्ट हो रहा है।
आपको कुछ चीजें करके इससे बचना चाहिए।
1 - यदि आपका क्लाइंट एप्लिकेशन http 1.1 प्रोटोकॉल का उपयोग नहीं कर रहा है तो आपको इसे 'keep-alive
http शीर्षलेख विकल्प के कारण उपयोग करने के लिए सेट करना होगा।
2 - आप ग्राहक http 1.1 चल रहा है और वह काम नहीं करता, या, यदि आप http 1.0 का उपयोग करना चाहिए, तो आप कनेक्शन अनुरोध हेडर गुण सेट करना चाहिए:
connection: keep-alive
इस सर्वर बताता है कि न तो अनुरोध पूरा करने के बाद क्लाइंट और न ही सर्वर को डिस्कनेक्ट करना चाहिए। ऐसा करने से आपका सर्वर प्राप्त होने वाले प्रत्येक अनुरोध के बाद डिस्कनेक्ट नहीं होगा।
3 - अपने ग्राहक में, अपनी सॉकेट का पुन: उपयोग करें। यदि आप उदाहरण के लिए लूप में बहुत से सॉकेट क्लाइंट बना रहे हैं, तो आपको एक बार सॉकेट बनाना चाहिए और जब भी आपको अनुरोध भेजने की आवश्यकता होती है तो उनका उपयोग होता है। मेरे ऐप में उपयोग किए जाने वाले दृष्टिकोण में सॉकेट पूल होना और एक सॉकेट उपलब्ध होना है (जो पहले से ही सर्वर से जुड़ा हुआ है और इसमें जीवित संपत्ति है)। फिर मैं इसका उपयोग करता हूं और जब मैं कर रहा हूं, तो मैंने पूल में इसे पुन: प्रयोज्य करने के लिए वापस रखा।
4 - यदि आपको अनुरोध भेजने के बाद वास्तव में डिस्कनेक्ट करने की आवश्यकता है, तो सुनिश्चित करें कि आपका क्लाइंट ऐसा करता है और connection: keep-alive
रखता है।
और हां, आपको समस्या हो सकती है जब आपके पास सर्वर की ओर बहुत नज़दीक_विट्स या टाइम_वाइट होता है।
यह [लिंक] [1] देखें जो बताता है कि keep-alive
क्या है।
मुझे आशा है कि यह सहायक होगा। उन चीजों के साथ मैं अपनी समस्या को हल करने में कामयाब रहा।
[1]: http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01.html#Persistent कनेक्शन
मुझे लगता है कि आप अपने उत्तर में close_wait और time_wait को गंभीरता से भ्रमित करते हैं। – wick
यह टीसीपी एफएसएम विनिर्देशों के अनुसार सही नहीं है। जब कोई प्रतिक्रिया भेजता है तो सर्वर डिस्कनेक्ट होने पर CLOSE_WAIT नहीं होता है। यह तब होता है जब ग्राहक (दूसरा अंत) एक टीसीपी कनेक्शन का अंतिम रूप शुरू करता है और क्लोज़() sys कॉल सर्वर पक्ष पर आवेदन द्वारा जारी नहीं किया जाता है (जैसा कि इस धागे पर ब्रायन व्हाइट द्वारा समझाया गया है) –
इसका मतलब यह हो सकता है कि आप अपने स्वीकृति() कॉल से सॉकेट पर "बंद" नहीं कह रहे हैं।
- 1. TCP कनेक्शन CLOSE_WAIT स्थिति पर लटका
- 2. समस्या निवारण heisenbug
- 3. समस्या निवारण system.io.fileloadexception
- 4. समस्या निवारण डबल पॉइंटर
- 5. समस्या निवारण कि
- 6. समस्या निवारण PHP मेल
- 7. सर्वर सॉकेट Close_Wait
- 8. बस त्रुटि समस्या निवारण
- 9. यात्रा विक्रेता समस्या निवारण प्रतिनिधित्व
- 10. SQL सर्वर टाइमआउट समस्या निवारण
- 11. समस्या निवारण JAXB unmarshalling एनपीई
- 12. एसक्यूएल सर्वर 2008 में डेडलॉक समस्या निवारण
- 13. सी प्रोग्राम में समस्या निवारण प्रिंटफ
- 14. Windows अनुसूचित कार्य समस्या निवारण कैसे करें?
- 15. समस्या निवारण त्रुटि एरेग() preg_match लिए()
- 16. समस्या निवारण Grails/ग्रोवी स्मृति रिसाव?
- 17. समस्या निवारण "टेम्पलेट डोज़ॉटएक्सएक्सिस्ट/अकाउंट्स/लॉगिन /"
- 18. एंड्रॉइड मीडियाप्लेयर तैयार में फंस गया()
- 19. टर्नरी ऑपरेटर स्टेटमेंट में "अप्रत्याशित T_ECHO" समस्या निवारण
- 20. समस्या निवारण 'WSGIRequest' ऑब्जेक्ट में कोई विशेषता 'उपयोगकर्ता' नहीं है?
- 21. समस्या निवारण के लिए मेकफ़ाइल लक्ष्य का पता कैसे लगाएं?
- 22. लगातार समस्या निवारण "SQLException: लॉक प्रतीक्षा टाइमआउट पार हो गया"
- 23. जावा JDBC कनेक्शन स्थिति
- 24. एसक्यूएल कनेक्शन स्ट्रिंग समस्या
- 25. http कनेक्शन टाइमआउट समस्या
- 26. postgres कनेक्शन की समस्या
- 27. समस्या: बाइट स्थिति
- 28. एंड्रॉयड ब्लूटूथ एकाधिक कनेक्शन समस्या?
- 29. स्थिति में एक PHP में समस्या
- 30. log4net एडोनेट एपेंडर कनेक्शन समस्या
क्या आप वाकई सर्वर पक्ष पर कनेक्शन बंद करते हैं? – weekens
क्या एप्लिकेशन अप्रतिबंधित होने से पहले वे CLOSE_WAIT के रूप में दिख रहे हैं? –
@ सप्ताहांत- मैं सर्वर की ओर से कनेक्शन बंद नहीं करता, WebLogic करता है। @ रॉबिन- हां, एक समान कॉन्फ़िगर किए गए सर्वर पर, मैं सर्वर को गिरने से पहले कनेक्शन जमा करता हूं। –