"सॉफ्टवेयर के कारण संबंध गर्भपात का कारण: सॉकेट लिखने में त्रुटि"

Question

इस स्टैक ट्रेस स्निपेट को देखते हुए

इसके कारण: java.net.SocketException: सॉफ़्टवेयर के कारण कनेक्शन निरस्त हो गया:
 java.net पर सॉकेट लिखने में त्रुटि ।

मैंने निम्नलिखित सवालों के जवाब देने की कोशिश की:

1. क्या कोड इस अपवाद को फेंक रहा है? (JVM? / Tomcat? / मेरा कोड?)
2. इस अपवाद का कारण क्या है?

# 1 के बारे में:

सूर्य के JVM स्रोत में यह सटीक संदेश नहीं है, लेकिन मुझे लगता है कि पाठ सॉफ़्टवेयर ने कनेक्शन का गर्भपात कर दिया है: सॉकेट लिखना त्रुटि मूल के कार्यान्वयन से है SocketOutputStream:

private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
                 int len) throws IOException;

# 2 के बारे में

मेरा अनुमान है कि यह तब होता है जब क्लाइंट ने पूर्ण प्रतिक्रिया प्राप्त करने से पहले कनेक्शन समाप्त कर दिया है (उदाहरण के लिए एक अनुरोध भेजा गया है, लेकिन पूर्ण प्रतिक्रिया प्राप्त करने से पहले, यह बंद / समाप्त / ऑफ़लाइन हो गया)

प्रशन:

1. क्या उपरोक्त धारणाएँ सही हैं (# 1 और # 2)?
2. क्या इसे स्थिति से अलग किया जा सकता है: " सर्वर पर नेटवर्क त्रुटि के कारण क्लाइंट को नहीं लिख सकता है "? या कि एक ही त्रुटि संदेश प्रस्तुत करना होगा?
3. और सबसे महत्वपूर्ण: क्या कोई आधिकारिक दस्तावेज (जैसे सूर्य से) उपरोक्त कहा गया है?

मुझे एक सबूत होना चाहिए कि यह स्टैक ट्रेस सॉकेट क्लाइंट की "गलती" है, और ऐसा कुछ भी नहीं है जो सर्वर इससे बचने के लिए कर सकता था। (अपवाद को पकड़ने के अलावा, या गैर सूर्य जेवीएम सॉकेटऑउटपुटस्ट्रीम का उपयोग करते हुए, हालांकि दोनों वास्तव में इस तथ्य से नहीं बचते हैं कि ग्राहक समाप्त हो गया है)

Comments

फ़ायरफ़ॉक्स के साथ डाउनलोड को रद्द करते समय मेरे पास यह मुद्दा है

— koppor

अरे Eran मैं भी इस अपवाद है, जबकि (लेखन / भेजने हो रही है outs.write(audioBytes);) byte[]करने के लिए OutputStream। जब ऑडियो पेंडिंग हो रहा हो और खेलते समय यदि उपयोगकर्ता किसी अन्य मेनू पर क्लिक करता है (जो एक सर्वर अनुरोध भेजता है) तो मुझे कंसोल पर वही त्रुटि मिली। तो क्या इस अपवाद को अनदेखा करना सुरक्षित है?

— अमोघ

@ अमोघ - ऐसा लगता है, हाँ। मूल रूप से जो उत्तर बताते हैं, यह एक विंडोज विशिष्ट त्रुटि है, लेकिन मैं लिनक्स पर मानता हूं कि आपको एक ही अपवाद मिलेगा एक अलग शब्दांकन के साथ ... (मेरे आम लोगों की समझ यह है कि मूल रूप से यह तब होता है जब आप भेजते हैं। एक सॉकेट के माध्यम से कुछ दूरस्थ स्थान पर एक्स और एक्स बीच में काट दिया गया, लेकिन मुझे यकीन है कि यह वर्णन करने का सबसे सटीक तरीका नहीं है)

— एरन मेडन

मेरे लिए यह तब हुआ जब डेटाबेस सर्वर को फिर से शुरू किया गया था और एप्लिकेशन अभी भी पहले से खोले गए कनेक्शन का उपयोग करके क्वेरी करने की कोशिश कर रहा था। सुनिश्चित नहीं हैं कि ये ताज़ा नहीं किए गए क्योंकि हम DBCP आधारित पूलिंग का उपयोग कर रहे हैं। लेकिन आवेदन को फिर से शुरू करने से समस्या ठीक हो गई।

— क्षितिज शर्मा

Answer 1

यह त्रुटि तब हो सकती है जब स्थानीय नेटवर्क सिस्टम एक कनेक्शन को निरस्त कर देता है, जैसे कि जब डेटा पुनर्प्राप्ति विफल होने के बाद WinSock एक स्थापित कनेक्शन को बंद कर देता है (रिसीवर कभी भी डेटास्ट्रीम सॉकेट पर भेजे गए डेटा को स्वीकार नहीं करता है)।

यह MSDN लेख देखें । यह भी देखें कि 'सॉफ़्टवेयर के कारण कनेक्शन गर्भपात' के बारे में कुछ जानकारी ।

Comments

WSAECONNABORTED - एक समझने योग्य स्पष्टीकरण

— Mat Gessel

@MatGessel यह लेख सिर्फ भ्रम को दोहराता है, और अपने स्वयं के कुछ जोड़ता है। WSAECONNABORTED एक Winsock त्रुटि कोड है, इसलिए संभवतः इसके लिए बर्कले स्पष्टीकरण नहीं हो सकता है। HTTP सर्वर के बारे में वर्णित स्थिति ECONNRESET का उत्पादन करेगी, WSAECONNABORTED की नहीं।

— लोरने की मारकिस

@EJP, मुझे आउटपुट (लेखन (ऑडियोबेसाइट्स);) बाइट] [] आउटपुटस्ट्रीम में भेजते समय यह अपवाद भी मिल रहा है। जब ऑडियो पेंडिंग हो रहा हो और खेलते समय यदि उपयोगकर्ता किसी अन्य मेनू पर क्लिक करता है (जो एक सर्वर अनुरोध भेजता है) तो मुझे कंसोल पर वही त्रुटि मिली। तो क्या इस अपवाद को अनदेखा करना सुरक्षित है?

— अमोघ

@rustyx सभी तीन स्रोतों ने यहां बताया कि यह ACK विफलताओं द्वारा निर्मित है। यदि आपके पास अपने स्वयं के दावे के लिए एक स्रोत है तो कृपया इसे उद्धृत करें।

— लोर्ने का मार्किव

यह एक वास्तविक जवाब नहीं है क्योंकि यह आपको समस्या को आगे बढ़ाने के लिए जानकारी नहीं देता है। यहां जवाब मूल रूप से "नेटवर्क पर कुछ बुरा हुआ" है। यह समझने में वास्तव में मददगार होगा कि आगे के लॉग और गतिविधि के अन्य रिकॉर्ड क्या मुझे अंतर्निहित मुद्दे को इंगित करने की अनुमति दे सकते हैं।

— डेरेक बेनेट

Answer 2

java.net.SocketExceptionजब वहाँ बनाने या पहुंचने में कोई त्रुटि है फेंक दिया जाता है एक सॉकेट (जैसे टीसीपी )। यह आमतौर पर तब हो सकता है जब सर्वर ने कनेक्शन समाप्त कर दिया है (ठीक से इसे बंद किए बिना), इसलिए पूर्ण प्रतिक्रिया प्राप्त करने से पहले। ज्यादातर मामलों में यह या तो टाइमआउट समस्या के कारण हो सकता है (जैसे प्रतिक्रिया में बहुत अधिक समय लगता है या सर्वर अनुरोधों के साथ अतिभारित होता है), या क्लाइंट ने SYN भेजा, लेकिन इसे ACK (कनेक्शन समाप्ति की स्वीकृति) प्राप्त नहीं हुआ । टाइमआउट मुद्दों के लिए, आप टाइमआउट मान बढ़ाने पर विचार कर सकते हैं।

सॉकेट अपवाद आमतौर पर मुद्दे के बारे में निर्दिष्ट विवरण संदेश के साथ आता है।

विस्तृत संदेशों का उदाहरण:

• सॉफ़्टवेयर के कारण कनेक्शन निरस्त हो गया: recv विफल।

  त्रुटि संदेश भेजने का प्रयास इंगित करती है और कनेक्शन आपके सर्वर द्वारा निरस्त कर दिया गया है। यदि डेटाबेस से कनेक्ट करते समय ऐसा हुआ है, तो यह संगत कनेक्टर / J JDBC ड्राइवर का उपयोग करने से संबंधित हो सकता है ।

  संभावित समाधान: सुनिश्चित करें कि आपने अपने CLASSPATH में उचित लाइब्रेरी / ड्राइवर बनाए हैं।

• सॉफ्टवेयर के कारण कनेक्शन गर्भपात: कनेक्ट।

  यह तब हो सकता है जब रिमोट से कनेक्ट करने में कोई समस्या हो। उदाहरण के लिए , दूरस्थ मेल अनुरोधों को अस्वीकार करने वाले वायरस-चेकर के कारण ।

  संभावित समाधान: वायरस स्कैन सेवा की जांच करें कि क्या यह कनेक्शन के लिए निवर्तमान अनुरोधों के लिए पोर्ट को अवरुद्ध कर रहा है।

• सॉफ़्टवेयर के कारण कनेक्शन निरस्त हो गया: सॉकेट त्रुटि लिखें।

  संभावित समाधान: सुनिश्चित करें कि आप स्ट्रीम को बाइट्स की सही लंबाई लिख रहे हैं। इसलिए जो आप भेज रहे हैं उसे दोबारा जांचें। इस धागे को देखें ।

• सहकर्मी द्वारा कनेक्शन रीसेट: सॉकेट राइट एरर / कनेक्शन पीयर द्वारा निरस्त: सॉकेट राइट एरर

  एप्लिकेशन ने यह जांच नहीं की कि क्या जीवित-जीवित कनेक्शन को सर्वर साइड पर टाइम-आउट किया गया था।

  संभावित समाधान: सुनिश्चित करें कि कनेक्शन से पढ़ने से पहले HttpClient गैर-अशक्त है। ^E13222_01

• हमउम्र द्वारा पुनःस्थापित संबंध।

  कनेक्शन को सहकर्मी (सर्वर) द्वारा समाप्त कर दिया गया है।

• सम्बन्ध फिरसे बनाना।

  अनुरोध के कारण अनुरोध के कारण कनेक्शन को क्लाइंट द्वारा या तो समाप्त कर दिया गया है या कनेक्शन के सर्वर अंत तक बंद कर दिया गया है।

  देखें: मेरे java.net.SocketException के कारण क्या है: कनेक्शन रीसेट?

Comments

इन 6 बिंदुओं में से केवल एक ही वास्तव में गलत तरीके से प्रश्न का उत्तर देता है। कई अन्य गलत भी हैं। आवेदन नहीं कर सकते 'की जांच के लिए कि क्या रखें जिंदा कनेक्शन सर्वर साइड पर का समय समाप्त हो गया था।' HttpClientकिया जा रहा है nullसंभवतः एक कारण नहीं हो सकता SocketException। स्ट्रीम के लिए सही लंबाई नहीं लिखना या तो नहीं है।

— लोर्ने

Answer 3

मैंने यह सबसे अधिक बार देखा है जब एक कार्य केंद्र / लैपटॉप पर कॉर्पोरेट फ़ायरवॉल रास्ते में मिलता है, तो यह कनेक्शन को मारता है।

जैसे। मेरे पास एक सर्वर प्रक्रिया और एक ग्राहक प्रक्रिया एक ही मशीन पर है। सर्वर सभी इंटरफेस (0.0.0.0) पर सुन रहा है और क्लाइंट सार्वजनिक / होम इंटरफ़ेस (लूपबैक इंटरफ़ेस 127.0.0.1 नहीं है) के लिए कनेक्शन का प्रयास करता है।

यदि मशीन का नेटवर्क बंद हो गया है (जैसे वाईफाई बंद हो गया है) तो कनेक्शन बनता है। यदि मशीन कॉर्पोरेट नेटवर्क (सीधे या वीपीएन) से जुड़ी है, तो कनेक्शन बनता है।

हालांकि, अगर मशीन एक सार्वजनिक वाईफाई (या होम नेटवर्क) से जुड़ी है, तो फ़ायरवॉल कनेक्शन को मारता है। इस स्थिति में क्लाइंट को लूपबैक इंटरफ़ेस से जोड़ना ठीक काम करता है, न कि घर / सार्वजनिक इंटरफ़ेस के लिए।

उम्मीद है की यह मदद करेगा।

Comments

फ़ायरवॉल कनेक्शन को रोकते हैं। प्रश्न मौजूदा कनेक्शन को रीसेट करने के बारे में है।

— लोर्ने

Answer 4

यह साबित करने के लिए कि कौन सा घटक विफल रहता है, मैं वायरशार्क का उपयोग करके टीसीपी / आईपी संचार की निगरानी करूंगा और यह देखूंगा कि कौन पोर्ट को बंद कर रहा है, टाइमआउट भी प्रासंगिक हो सकता है।

Comments

कोई भी बंदरगाह को बंद नहीं कर रहा है। ऑपरेटिंग सिस्टम कनेक्शन को निरस्त कर रहा है।

— लोर्ने

@EJP मैंने देखा है जब यह अतिभारित हो जाता है और स्मृति से बाहर निकल जाता है। मुझे यकीन नहीं है कि यह ओएस है जो कनेक्शन को बंद कर देता है लेकिन जेवीएम जंगली हो जाता है।

— ज़ी

@Zee एक पोर्ट को बंद करने के बीच एक अंतर है, जो विंडसरक में एक फिन के रूप में दिखाई देता है, और कनेक्शन को निरस्त कर रहा है, जो नहीं है।

— लोरेन का मार्किव

Answer 5

क्या आपने टॉमकैट स्रोत कोड और जेवीएम स्रोत की जांच की है? इससे आपको और मदद मिल सकती है।

मुझे लगता है कि आपकी सामान्य सोच अच्छी है। मुझे उम्मीद ConnectExceptionहै कि इस परिदृश्य में आप कनेक्ट नहीं कर सकते। ऊपर बहुत लग रहा है जैसे यह ग्राहक-चालित है।

Comments

हाँ, मैंने जाँच की है। टॉम्कट के स्रोतों में वाक्य का कोई भी क्रमचय नहीं था, धन्यवाद।

— एरन मेडन

नहीं, उसने टॉमकैट स्रोत और जेवीएम स्रोत की जांच नहीं की है ।

— स्टीफन सी

या अगर उसने जेवीएम स्रोत की जांच की है, तो उसने सभी की जांच नहीं की है।

— स्टीफन सी

@ ईशान - संदेश स्ट्रिंग मूल स्रोतों में सबसे अधिक संभावना है। लेकिन आपको इवेंट लॉग की भी जांच करनी चाहिए। IMO, उत्तरार्द्ध अधिक जानकारीपूर्ण होने की संभावना है।

— स्टीफन सी

यह संदेश स्ट्रिंग वास्तव में ऑपरेटिंग सिस्टम से आता है।

— लोर्ने

Answer 6

सरल क्लाइंट सर्वर प्रोग्रामों का उपयोग करने वाले और इस त्रुटि को प्राप्त करने वाले किसी के लिए, यह इनपुट या आउटपुट धाराओं के बिना (या बंद होने की) समस्या है।

Comments

नहीं, यह नहीं है। यह एक सॉकेट रिसाव को मान्य करेगा, जो अंततः एफडी थकावट का कारण होगा।

— लोरेन का मार्किव

Answer 7

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

उम्मीद है की यह मदद करेगा।
और अगर अभी भी समस्या का सामना करना पड़ रहा है तो अपनी समस्या का विवरण यहां दें।

Comments

@BhavinChhatrola नहीं, एक गलत जवाब। वर्णित स्थिति प्रश्न में त्रुटि नहीं, 'सहकर्मी द्वारा कनेक्शन रीसेट' का उत्पादन करती है।

— लोर्ने

Answer 8

SoapUI क्लाइंट के साथ मेरी साबुन सेवा का परीक्षण करते समय यह त्रुटि हुई, मूल रूप से मैं एक बहुत बड़ा संदेश प्राप्त करने की कोशिश कर रहा था (> 500kb) और SoapUI ने टाइमआउट द्वारा कनेक्शन को बंद कर दिया।

SoapUI पर जाएं:

फ़ाइल -> वरीयताएँ - सॉकेट टाइमआउट (एमएस)

... और 180000 (3 मिनट) जैसे एक बड़े मूल्य को रखो, यह आपके मुद्दे के लिए बिल्कुल ठीक नहीं होगा क्योंकि फ़ाइल वास्तव में बड़ी है, लेकिन कम से कम आपके पास प्रतिक्रिया होगी।

Answer 9

किसी अन्य क्लाइंट में बंद कनेक्शन

मेरे मामले में, त्रुटि यह थी:

java.net.SocketException: Software caused connection abort: recv failed

यह एक H2 डेटाबेस तक पहुँचने वाले जावा एप्लिकेशन को डीबग करते हुए ग्रहण में प्राप्त हुआ था। त्रुटि का स्रोत यह था कि मैंने शुरुआत में अखंडता के लिए मैन्युअल रूप से जांच करने के लिए SQuirreL के साथ डेटाबेस खोला था। मैंने एक ही DB (यानी AUTO_SERVER=TRUE) को कई कनेक्शनों को सक्षम करने के लिए ध्वज का उपयोग किया था , इसलिए जावा से DB को जोड़ने में कोई समस्या नहीं थी।

त्रुटि तब दिखाई दी, जब थोड़ी देर बाद - यह एक लंबी जावा प्रक्रिया है - मैंने नि: शुल्क संसाधनों के लिए SQuirreL को बंद करने का फैसला किया। ऐसा प्रतीत होता है मानो SQuirreL DB सर्वर उदाहरण "एक" का मालिक था और यह SQuirreL कनेक्शन के साथ बंद हो गया था।

जावा एप्लिकेशन को पुनरारंभ करने से त्रुटि फिर से नहीं हुई।

config

• विंडोज 7
• ग्रहण केपलर
• SQuirreL 3.6
• org.h2.river ver 1.4.192

Answer 10

मेरे मामले में, मैंने ग्राहक और सर्वर पक्ष को विकसित किया, और मेरे पास अपवाद है:

कारण: त्रुटि मार्शलिंग तर्क; नेस्टेड अपवाद है: java.net.SocketException: सॉफ़्टवेयर के कारण कनेक्शन का गर्भपात: सॉकेट लिखना त्रुटि है

जब क्लायंट और सर्वर में कक्षाएं अलग होती हैं। मैं क्लाइंट पर सर्वर की कक्षाएं (इंटरफेस) डाउनलोड नहीं करता, मैं प्रोजेक्ट में एक ही फाइल जोड़ता हूं। लेकिन रास्ता बिल्कुल वैसा ही होना चाहिए। उदाहरण के लिए, सर्वर प्रोजेक्ट पर मेरे पास कुछ सर्विसइंटरफेस और कार्यान्वयन के साथ java \ rmi \ Services पैकेज हैं, मुझे क्लाइंट प्रोजेक्ट पर एक ही पैकेज बनाना है। यदि मैं उदाहरण के लिए जावा / आरएमआई / सर्वर / सेवाओं द्वारा इसे बदलता हूं, तो मुझे उपरोक्त अपवाद मिलता है। एक ही अपवाद अगर इंटरफ़ेस संस्करण क्लाइंट और सर्वर के बीच भिन्न है (यहां तक ​​कि अनजाने में जोड़ी गई एक खाली पंक्ति के साथ ... मुझे लगता है कि rmi संस्करण की जांच करने के लिए कक्षाओं का एक प्रकार का हैश बनाता है ... मुझे नहीं पता ... यदि यह हो सकता है मदद ...

Answer 11

मेरा सर्वर 2 दिनों में इस अपवाद को फेंक रहा था और मैंने इसे डिस्कनेक्ट करने के कार्य को हल करके इसे हल किया:

outputStream.close();
inputStream.close();
Client.close();

लिस्टिंग थ्रेड के अंत तक। अगर यह किसी की मदद करेगा।

Answer 12

नीचे बताई गई स्थिति में, ग्राहक पक्ष इस तरह के अपवाद को फेंक देगा:

सर्वर को क्लाइंट सर्टिफिकेट को प्रमाणित करने के लिए कहा जाता है, लेकिन क्लाइंट एक सर्टिफिकेट प्रदान करता है, जिसे एक्सटेंडेड की यूज़ क्लाइंट सपोर्ट को सपोर्ट नहीं करता है, इसलिए सर्वर क्लाइंट के सर्टिफिकेट को स्वीकार नहीं करता है, और फिर वह कनेक्शन बंद कर देता है।

Comments

यह उत्तर गलत है। मामले में आप एक SSLException का वर्णन करते हैं।

— राष्ट्रपति जेम्स के। पोल्क

वास्तव में यह वर्तमान प्रश्न की तरह सॉकेटएक्सैप्शन को फेंक देता है, मैंने परीक्षण किया था

— xiaoming

Answer 13

ssl ग्राहक पक्ष नीचे की स्थिति में इस तरह के अपवाद को फेंक देगा tested मैंने परीक्षण किया था side:

सर्वर को क्लाइंट सर्टिफिकेट को प्रमाणित करने के लिए कहा जाता है, लेकिन क्लाइंट एक सर्टिफिकेट प्रदान करता है, जो किड यूज़ डोनेट सपोर्ट क्लाइंट ऑस्ट्रलिटी को विस्तारित करता है।

Answer 14

बाकी API कॉल्स का मज़ाक उड़ाते हुए मुझे वायरमॉक के साथ भी यही समस्या आ रही थी। पहले मैं सर्वर को इस तरह परिभाषित कर रहा था:

WireMockServer wireMockServer = null;

लेकिन इसे नीचे दिखाए अनुसार परिभाषित किया जाना चाहिए:

@Rule 
public WireMockRule wireMockRule = new WireMockRule(8089);

Comments

NullPointerExceptionइस समस्या का कारण होगा ।

— लोर्ने