एस 3 जावा क्लाइंट "सामग्री-लंबाई सीमित संदेश निकाय का समयपूर्व अंत" या "java.net.SocketException सॉकेट बंद"

Question

मेरे पास एक ऐसा एप्लिकेशन है जो S3 पर बहुत अधिक काम करता है, अधिकतर इससे फ़ाइलें डाउनलोड करता है। मुझे इस तरह की कई त्रुटियां दिखाई दे रही हैं और मैं जानना चाहता हूं कि यह मेरे कोड पर कुछ है या यदि सेवा वास्तव में अविश्वसनीय है।

कोड मैं S3 वस्तु स्ट्रीम से पढ़ने का उपयोग कर रहा हूँ इस प्रकार है:

public static final void write(InputStream stream, OutputStream output) { 

    byte[] buffer = new byte[1024]; 

    int read = -1; 

    try { 

    while ((read = stream.read(buffer)) != -1) { 
     output.write(buffer, 0, read); 
    } 

    stream.close(); 
    output.flush(); 
    output.close(); 
    } catch (IOException e) { 
    throw new RuntimeException(e); 
    } 

} 

यह OutputStream एक नई BufferedOutputStream (नई FileOutputStream (फाइल)) है। मैं अमेज़ॅन एस 3 जावा क्लाइंट का नवीनतम संस्करण उपयोग कर रहा हूं और इस कॉल को छोड़ने से पहले चार बार पुनः प्रयास किया गया है। तो, इसे 4 बार करने की कोशिश करने के बाद भी यह विफल हो जाता है।

किसी भी संकेत या सुझाव कि मैं इसे कैसे संभवतः सुधार सकता हूं, इसकी सराहना की जाती है।

Answer 1

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

समस्या के मूल कारण है कि AmazonS3Client वस्तु डाउनलोड, जो नेटवर्क कनेक्शन को तोड़ने के लिए कारण होता है के बीच में कचरा एकत्र हो रही थी थी। ऐसा इसलिए हुआ क्योंकि मैं एक फ़ाइल को लोड करने के लिए प्रत्येक कॉल के साथ एक नया AmazonS3Client ऑब्जेक्ट का निर्माण कर रहा था, जबकि पसंदीदा उपयोग केस एक लंबे समय तक चलने वाली क्लाइंट ऑब्जेक्ट बनाना है जो पूरे कॉल में रहता है - या कम से कम पूरी तरह से आसपास की होने की गारंटी है डाउनलोड। इसलिए, सरल उपाय यह सुनिश्चित करना है कि AmazonS3Client के संदर्भ को चारों ओर रखा जाए ताकि उसे GC'd न मिले।

एडब्ल्यूएस मंचों कि मुझे मदद की पर एक लिंक यहाँ है: https://forums.aws.amazon.com/thread.jspa?threadID=83326

Answer 2

1. देखने के लिए तार पर हो रहा है जब ऐसा होता है wireshark का उपयोग करें।

2. अस्थायी रूप से अपने स्वयं के वेब सर्वर के साथ S3 को बदलने का प्रयास करें और देखें कि समस्या बनी रहती है या नहीं। अगर ऐसा होता है तो यह आपका कोड है और एस 3 नहीं।

तथ्य यह है कि यह यादृच्छिक है आपके मेजबान और S3 सेनाओं के कुछ के बीच नेटवर्क मुद्दों पता चलता है।

Answer 3

सबसे पहले, आपका कोड पूरी तरह से सामान्य रूप से परिचालन कर रहा है अगर (और केवल अगर) आप अपने और अमेज़ॅन एस 3 के बीच कनेक्टिविटी परेशानियों को पीड़ित करते हैं। माइकल स्लैड points out के रूप में, मानक कनेक्शन-स्तर डीबगिंग सलाह लागू होती है।

आपके वास्तविक स्रोत कोड के रूप में, मुझे कुछ कोड गंधों को नोट किया गया है जिनके बारे में आपको अवगत होना चाहिए। उन्हें सीधे टिप्पणी करना स्रोत में:

public static final void write(InputStream stream, OutputStream output) { 

    byte[] buffer = new byte[1024]; // !! Abstract 1024 into a constant to make 
            // this easier to configure and understand. 

    int read = -1; 

    try { 

    while ((read = stream.read(buffer)) != -1) { 
     output.write(buffer, 0, read); 
    } 

    stream.close(); // !! Unexpected side effects: closing of your passed in 
        // InputStream. This may have unexpected results if your 
        // stream type supports reset, and currently carries no 
        // visible documentation. 

    output.flush(); // !! Violation of RAII. Refactor this into a finally block, 
    output.close(); // a la Reference 1 (below). 

    } catch (IOException e) { 
    throw new RuntimeException(e); // !! Possibly indicative of an outer 
            // try-catch block for RuntimeException. 
            // Consider keeping this as IOException. 
    } 
} 

(Reference 1)

अन्यथा, कोड में ही ठीक लग रहा है। आईओ अपवादों को उन परिस्थितियों में होने वाली घटनाओं की अपेक्षा की जानी चाहिए जहां आप एक चंचल रिमोट होस्ट से कनेक्ट हो रहे हैं, और इन परिदृश्यों में कैश करने और फिर से कनेक्ट करने के लिए एक सैक पॉलिसी तैयार करना है।

Answer 4

इसके अलावा एस 3 मेरे अनुभव के अनुसार धीमी कनेक्शन बंद कर सकता है।

Answer 5

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

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

Answer 6

नेटवर्क कनेक्शन, ग्राहक सभी डेटा, एक या अन्य कारणों के लिए हो रही करने से पहले बंद हो रहा है, कि क्या चल रहा है है।

किसी भी HTTP अनुरोध का हिस्सा सामग्री की लंबाई है, आपका कोड हेडर प्राप्त कर रहा है, यह कह रहा है कि हे दोस्त, यहां डेटा है, और इसका बहुत कुछ .. और फिर क्लाइंट ने सभी को पढ़ने से पहले कनेक्शन छोड़ दिया है डेटा .. तो अपवाद के साथ इसके बमबारी बाहर।

मैं अपने ओएस/नेटवर्क/JVM कनेक्शन टाइमआउट सेटिंग को देखो चाहते हैं (हालांकि JVM आम तौर पर इस स्थिति में ओएस से विरासत)। कुंजी यह पता लगाने के लिए है कि नेटवर्क का कौन सा हिस्सा समस्या पैदा कर रहा है। क्या यह आपके कंप्यूटर स्तर की सेटिंग्स कह रहा है, अब पैकेट के लिए इंतजार नहीं कर रहा है .. क्या यह है कि आप एक गैर-अवरुद्ध पढ़ने का उपयोग कर रहे हैं, जिसमें आपके कोड में टाइमआउट सेटिंग है, जहां यह कह रहा है, हे, नहीं मिला है सर्वर से किसी भी डेटा को लंबे समय से इंतजार करना है, इसलिए मैं कनेक्शन और अपवाद छोड़ने जा रहा हूं। आदि इत्यादि।

सर्वश्रेष्ठ शर्त पैकेट ट्रैफिक को स्नूप करें और पीछे की ओर ट्रेस करें, यह देखने के लिए कि कनेक्शन ड्रॉप कहां हो रहा है, या देखें कि आप उन चीज़ों में टाइमआउट कर सकते हैं जिन्हें आप नियंत्रित कर सकते हैं, जैसे कि आपके सॉफ़्टवेयर और ओएस/JVM।