कोई छवि तेज़ सीधे कनेक्शन पर काम करती है, लेकिन धीमे फ़ॉरवर्ड प्रॉक्सी से अधूरी आती है। एक संभावित कारण यह है कि ओरिजिन कनेक्शन बंद कर देता है जबकि उसकी प्रतिक्रिया अभी लिखी जा रही है।

Netty I/O अतुल्यकालिक है। writeAndFlush से लौटने का मतलब यह नहीं कि वह क्रिया पूरी हो गई। इसलिए यह क्रम ऐसी प्रतिक्रिया के लिए सुरक्षित नहीं है जिसमें अभी कतार में बाइट्स हैं:

ctx.writeAndFlush(response);
ctx.close();

जब HTTP विनिमय अपने अंतिम प्रतिक्रिया संदेश के बाद जानबूझकर बंद हो रहा हो, तो बंद होने को उस लेखन के future से जोड़ें:

ctx.writeAndFlush(finalResponseMessage)
    .addListener(ChannelFutureListener.CLOSE);

यह अंश मानता है कि प्रतिक्रिया पहले से सही ढंग से बनाई और फ़्रेम की गई है। स्ट्रीम किए गए बॉडी के लिए उसके अंतिम संदेश का पूरा होना उपयोग करें, हेडर का लेखन नहीं। लगातार HTTP कनेक्शन के लिए, केवल इसलिए बंद न जोड़ें कि प्रतिक्रिया समाप्त हो गई।

एप्लिकेशन की सामान्य त्रुटि-प्रबंधन के हिस्से के रूप में future की विफलता जाँचें। पूर्णता में विफलता और रद्दीकरण भी शामिल हैं, इसलिए केवल पूर्णता ब्राउज़र से डिलीवरी की रसीद नहीं है।

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

संबंधित लेख