2011-04-12 13 views
20

मेरे पास जावा पर वेबलॉगिक 11 जी में चल रहा जावा एप्लिकेशन है, जो कई दिनों के बाद, उत्तरदायी नहीं हो जाता है। एक संदेहजनक लक्षण मैंने देखा है कि सर्वर की निष्क्रिय होने पर भी CLOSE_WAIT स्थिति के साथ netstat में बड़ी संख्या में कनेक्शन (लगभग 3000) दिखाई देते हैं। चूंकि एप्लिकेशन सर्वर क्लाइंट कनेक्शन का प्रबंधन कर रहा है, इसलिए मुझे यकीन नहीं है कि इसका क्या कारण है। हम कई वेब सेवा कॉल भी करते हैं जो एक ही सर्वर पर लूपबैक करते हैं, लेकिन मेरा मानना ​​है कि वे कनेक्शन ठीक से बंद हो जाते हैं। इसका और क्या कारण हो सकता है और इस तरह की समस्या का निवारण कैसे करता है?CLOSE_WAIT स्थिति में फंस गए समस्या निवारण कनेक्शन

+0

क्या आप वाकई सर्वर पक्ष पर कनेक्शन बंद करते हैं? – weekens

+0

क्या एप्लिकेशन अप्रतिबंधित होने से पहले वे CLOSE_WAIT के रूप में दिख रहे हैं? –

+0

@ सप्ताहांत- मैं सर्वर की ओर से कनेक्शन बंद नहीं करता, WebLogic करता है। @ रॉबिन- हां, एक समान कॉन्फ़िगर किए गए सर्वर पर, मैं सर्वर को गिरने से पहले कनेक्शन जमा करता हूं। –

उत्तर

1

समस्या एक बग WebLogic में सच करने के लिए "का प्रयोग करें JSSE एसएसएल" सेटिंग से शुरू हो रहा था। जेएसएसई के बजाय वेबलॉगिक के अपने एसएसएल कार्यान्वयन का उपयोग करना हमारे आवेदन के लिए कोई समस्या नहीं है, इसलिए मैंने केवल उस सेटिंग को अनचेक कर दिया और समस्या गायब हो गई।

0

मैं CLOSE_WAIT pileups के बारे में इस उद्धरण मिला: "कुछ या तो को प्रगति को रोकने HTTP सत्र में होते है (हम फंस रहे हैं तो अंत कभी नहीं पास बुला), या कुछ बग शुरू किया गया है कि बंद किया जा रहा से सॉकेट से बचाता है ऐसा होने के कई तरीके हैं। "

सोचें: क्या कोई अनुरोध संसाधित करते समय आपका एप्लिकेशन अटक जा रहा है? या WebLogic खुद?

जांच: क्या आप जावा थ्रेड डंप कर सकते हैं (मारने के लिए सिग्क्विट का उपयोग ओरेकल जेवीएम पर लिनक्स के लिए किया जा सकता है) यह देखने के लिए कि वास्तव में आपके किसी भी थ्रेड फंस रहे हैं?

ग्राहक पक्ष की जांच करें: सबसे पहले, CLOSE_WAIT सॉकेट से जुड़े क्लाइंट के आईपी पते या होस्टनाम का पता लगाएं। फिर, देखें कि उन ग्राहकों पर कुछ भी संदिग्ध हो रहा है या नहीं।

4

CLOSE_WAIT स्थिति का मतलब है कि दूसरी तरफ कनेक्शन बंद हो गया है, लेकिन स्थानीय पक्ष के आवेदन ने अभी तक सॉकेट बंद नहीं किया है।

ऐसा लगता है कि आपके स्थानीय एप्लिकेशन में एक बग है।

14

CLOSE_WAIT राज्य स्थानीय टीसीपी राज्य मशीन है जब रिमोट होस्ट एक एफआईएन भेजता है (इसका कनेक्शन बंद करता है) लेकिन स्थानीय एप्लिकेशन ने ऐसा नहीं किया है और एक जवाब भेजा है। स्थानीय मशीन के लिए इस बिंदु पर डेटा भेजने के लिए अभी भी संभव है हालांकि क्लाइंट इसे प्राप्त नहीं कर सकता है (जब तक कि यह कनेक्शन पर केवल आधे बंद न हो)।

जब रिमोट होस्ट बंद हो जाता है (एक एफआईएन भेजता है), तो आपके स्थानीय एप्लिकेशन को कुछ प्रकार की घटना मिल जाएगी (यह बेस सी लाइब्रेरी में सॉकेट पर "पढ़ा" ईवेंट है) लेकिन उस कनेक्शन से पढ़ने से एक त्रुटि वापस आ जाएगी यह इंगित करने के लिए कि कनेक्शन बंद हो गया है। इस बिंदु पर स्थानीय आवेदन कनेक्शन बंद करना चाहिए।

मुझे जावा के बारे में कुछ पता नहीं है और वेबलॉगिक के बारे में कुछ भी नहीं है, लेकिन मुझे लगता है कि यह संभव है कि एप्लिकेशन पढ़ने की त्रुटि को ठीक से संभाल नहीं रहा है और इस प्रकार कनेक्शन को कभी बंद नहीं कर रहा है।

17

मुझे एक ही समस्या है और मैं इस मुद्दे से छुटकारा पाने के लिए सॉकेट का अध्ययन कर रहा हूं।

मुझे कुछ शब्द कहने दो, लेकिन इससे पहले कि मुझे कहना होगा कि मैं जावा प्रोग्रामर नहीं हूं।

मैं यह नहीं समझाऊंगा कि 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 कनेक्शन

+3

मुझे लगता है कि आप अपने उत्तर में close_wait और time_wait को गंभीरता से भ्रमित करते हैं। – wick

+0

यह टीसीपी एफएसएम विनिर्देशों के अनुसार सही नहीं है। जब कोई प्रतिक्रिया भेजता है तो सर्वर डिस्कनेक्ट होने पर CLOSE_WAIT नहीं होता है। यह तब होता है जब ग्राहक (दूसरा अंत) एक टीसीपी कनेक्शन का अंतिम रूप शुरू करता है और क्लोज़() sys कॉल सर्वर पक्ष पर आवेदन द्वारा जारी नहीं किया जाता है (जैसा कि इस धागे पर ब्रायन व्हाइट द्वारा समझाया गया है) –

0

इसका मतलब यह हो सकता है कि आप अपने स्वीकृति() कॉल से सॉकेट पर "बंद" नहीं कह रहे हैं।

संबंधित मुद्दे