कुछ ओटीएन मंचों (https://kr.forums.oracle.com/forums/thread.jspa?messageID=3699989) में इस समस्या का समाधान उपलब्ध कराया गया है। लेकिन, समस्या का मूल कारण स्पष्ट नहीं किया गया है। समस्या के मूल कारण को समझाने का मेरा प्रयास निम्नलिखित है।
Oracle JDBC ड्राइवर Oracle सर्वर के साथ सुरक्षित तरीके से संचार करते हैं। ड्राइवर java.security.SecureRandom . का उपयोग करते हैं संचार को सुरक्षित करने के लिए एंट्रोपी इकट्ठा करने के लिए कक्षा। यह वर्ग एन्ट्रापी एकत्र करने के लिए स्थानीय मंच समर्थन पर निर्भर करता है।
एंट्रॉपी क्रिप्टोग्राफी या अन्य उपयोगों में उपयोग के लिए एक ऑपरेटिंग सिस्टम या एप्लिकेशन द्वारा एकत्रित / उत्पन्न यादृच्छिकता है जिसके लिए यादृच्छिक डेटा की आवश्यकता होती है। यह यादृच्छिकता अक्सर हार्डवेयर स्रोतों से एकत्र की जाती है, या तो हार्डवेयर शोर, ऑडियो डेटा, माउस आंदोलनों या विशेष रूप से प्रदान किए गए यादृच्छिक जनरेटर से। कर्नेल एन्ट्रापी को इकट्ठा करता है और इसे एक एन्ट्रापी पूल में संग्रहीत करता है और विशेष फाइलों के माध्यम से ऑपरेटिंग सिस्टम प्रक्रियाओं या अनुप्रयोगों के लिए यादृच्छिक वर्ण डेटा उपलब्ध कराता है /dev/random और /dev/urandom .
/dev/random . से पढ़ना अनुरोधित मात्रा में बिट्स/बाइट्स के साथ एन्ट्रापी पूल को हटाता है, क्रिप्टोग्राफिक संचालन में अक्सर वांछित उच्च स्तर की यादृच्छिकता प्रदान करता है। मामले में, यदि एन्ट्रापी पूल पूरी तरह से सूखा हुआ है और पर्याप्त एन्ट्रापी उपलब्ध नहीं है, तो /dev/random पर रीड ऑपरेशन करें। अतिरिक्त एन्ट्रापी इकट्ठा होने तक ब्लॉक। इसके कारण, /dev/random . से पढ़ने वाले एप्लिकेशन कुछ यादृच्छिक अवधि के लिए अवरुद्ध हो सकता है।
उपरोक्त के विपरीत, /dev/urandom . से पढ़ना ब्लॉक नहीं करता। /dev/urandom . से पढ़ना , भी, एन्ट्रापी पूल को हटा देता है, लेकिन जब पर्याप्त एन्ट्रापी की कमी होती है, तो यह ब्लॉक नहीं होता है, लेकिन आंशिक रूप से पढ़े गए यादृच्छिक डेटा से बिट्स का पुन:उपयोग करता है। इसे क्रिप्टोएनालिटिकल हमलों के लिए अतिसंवेदनशील कहा जाता है। यह एक सैद्धांतिक संभावना है और इसलिए इसे /dev/urandom से पढ़ने के लिए हतोत्साहित किया जाता है क्रिप्टोग्राफ़िक संचालन में यादृच्छिकता इकट्ठा करने के लिए।
java.security.SecureRandom वर्ग, डिफ़ॉल्ट रूप से, /dev/random . से पढ़ता है फ़ाइल और इसलिए कभी-कभी यादृच्छिक अवधि के लिए अवरुद्ध हो जाती है। अब, यदि रीड ऑपरेशन आवश्यक समय के लिए वापस नहीं आता है, तो Oracle सर्वर क्लाइंट (इस मामले में jdbc ड्राइवर) को टाइम आउट कर देता है और इसके अंत से सॉकेट को बंद करके संचार को छोड़ देता है। क्लाइंट जब ब्लॉकिंग कॉल से लौटने के बाद संचार को फिर से शुरू करने का प्रयास करता है तो आईओ अपवाद का सामना करता है। यह समस्या बेतरतीब ढंग से किसी भी प्लेटफ़ॉर्म पर हो सकती है, विशेष रूप से, जहाँ हार्डवेयर शोर से एन्ट्रॉपी एकत्र की जाती है।
जैसा कि ओटीएन फोरम में सुझाया गया है, इस समस्या का समाधान java.security.SecureRandom के डिफ़ॉल्ट व्यवहार को ओवरराइड करना है। /dev/urandom . से गैर-अवरुद्ध पठन का उपयोग करने के लिए वर्ग /dev/random . से पढ़ने को ब्लॉक करने के बजाय . यह निम्नलिखित सिस्टम गुण जोड़कर किया जा सकता है -Djava.security.egd=file:///dev/urandom जेवीएम को। हालांकि यह JDBC ड्राइवरों जैसे अनुप्रयोगों के लिए एक अच्छा समाधान है, यह उन अनुप्रयोगों के लिए हतोत्साहित किया जाता है जो क्रायोग्राफिक कुंजी पीढ़ी जैसे कोर क्रिप्टोग्राफ़िक संचालन करते हैं।
अन्य समाधान प्लेटफॉर्म के लिए उपलब्ध विभिन्न यादृच्छिक बीजक कार्यान्वयन का उपयोग करना हो सकता है जो एन्ट्रॉपी एकत्र करने के लिए हार्डवेयर शोर पर भरोसा नहीं करते हैं। इसके साथ, आपको अभी भी java.security.SecureRandom के डिफ़ॉल्ट व्यवहार को ओवरराइड करने की आवश्यकता हो सकती है .
Oracle सर्वर साइड पर सॉकेट टाइमआउट बढ़ाना भी एक समाधान हो सकता है लेकिन इसे करने से पहले सर्वर के दृष्टिकोण से साइड इफेक्ट का आकलन किया जाना चाहिए।
