पिन किए गए ऑब्जेक्ट ओवरफ़्लो अपवाद?

Question

हालांकि लॉग में त्रुटि से नीचे हो रही है। मुझे यूआई या प्रदर्शन की तरह मेरे आवेदन पर इसका कोई भी प्रभाव दिखाई नहीं देता है। वेबलॉगिक Jrockit JVM का उपयोग करना।

Caused by: java.lang.InternalError: pinned object overflow! 
    at java.util.zip.Inflater.inflateBytes(Inflater.java:381) ~[na:1.6.0_31] 
    at java.util.zip.Inflater.inflate(Inflater.java:231) ~[na:1.6.0_31] 
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:135) ~[na:1.6.0_31] 
    at java.io.FilterInputStream.read(FilterInputStream.java:116) ~[na:1.6.0_31] 
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) ~[na:1.6.0_31] 

शुद्ध पर, मैं कुछ भी pinned object overflow अपवाद के लिए विशिष्ट नहीं पाते हैं। मेरे लिए यह प्रोग्रामिंग समस्या की तरह नहीं दिखता है लेकिन वेबलॉगिक या जॉकिट से संबंधित समस्या है?

कोई भी पॉइंटर्स मैं इससे कैसे छुटकारा पा सकता हूं?

Answer 1

को पिन वस्तु ?:

पहले लगाए Object.Basically समझने की कोशिश करें, को पिन है whe फिर हम अस्थायी रूप से ढेर पर एक वस्तु को टैग इतना है कि कचरा कलेक्टर जब तक वस्तु को स्थानांतरित करने का प्रयास नहीं करेंगे हम टैग हटा देते हैं। आम तौर पर, यदि किसी वस्तु को प्रचारित किया जा रहा है (यानी युवा स्थान से पुरानी जगह में स्थानांतरित किया जा रहा है) या कंपैक्शन (डीफ्रैग्मेंटेशन) के हिस्से के रूप में एक ऑब्जेक्ट को एक पते से दूसरे स्थान पर ले जाया जा सकता है। लेकिन अगर किसी वस्तु को पिन किया जाता है, तो जीसी इसे तब तक स्थानांतरित करने की कोशिश नहीं करेगा जब तक कि यह अनपिन नहीं हो जाता है।

तो हम एक ऑब्जेक्ट पिन क्यों करना चाहते हैं?।

पिनिंग केवल प्रदर्शन अनुकूलन के लिए महत्वपूर्ण है। एक I/O ऑपरेशन के दौरान एक बफर (एक बाइट सरणी) पिन करना हमें अपने पते को सीधे ऑपरेटिंग सिस्टम पर सौंपने की अनुमति देता है। चूंकि बफर पिन किया गया है, इसलिए हमें चिंता करने की आवश्यकता नहीं है कि कचरा कलेक्टर I/O ऑपरेशन समाप्त होने से पहले इसे किसी भिन्न पते पर ले जाने का प्रयास करेगा।

अगर हम बफर को पिन करने में सक्षम नहीं थे, तो हमें ओएस के मूल I/O कॉल को पास करने के लिए अतिरिक्त देशी (ऑफ-हेप) मेमोरी आवंटित करने की आवश्यकता होगी और ऑन-हीप और ऑफ़-हेप के बीच डेटा कॉपी भी करना होगा बफ़र्स।

तो बफर को ढेर पर एक स्थिर पते पर पिन करके, हम दोनों को अन्यथा अनावश्यक देशी स्मृति आवंटन और एक प्रतिलिपि करने से बचते हैं।

जब पिन ऑब्जेक्ट ओवरफ़्लो हो सकता है?

यह दृश्य जेएनआई कॉल या आई/ओ कॉल में खराब अपवाद हैंडलिंग के दौरान हो सकता है। असली तथ्य जानने के लिए, हमें यह पता लगाने के लिए थ्रेड डंप का विश्लेषण करना होगा कि कितने धागे अवरुद्ध हैं यानी। stucked।

समस्या निवारण:

तो जब आप एक धागा प्रकट होता है कि readBytesPinned के लिए एक कॉल में फंस या writeBytesPinned है आप क्या करना चाहिए? यह पूरी तरह से इस बात पर निर्भर करता है कि एप्लिकेशन डेटा को डेटा पढ़ने या लिखने का प्रयास कर रहा है।

एक धागे की एक वास्तविक दुनिया उदाहरण एक अवरुद्ध कर अटक पर देखने की सुविधा देता है पढ़ें:

"ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=20 idx=0x2e tid=16946 prio=5 alive, in native, daemon 
     at jrockit/net/SocketNativeIO.readBytesPinned(I[BIII)I(Native Method) 
     at jrockit/net/SocketNativeIO.socketRead(Ljava/io/FileDescriptor;[BIII)I(Unknown Source)[inlined] 
     at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(Unknown Source)[inlined] 
     at java/net/SocketInputStream.read([BII)I(SocketInputStream.java:113)[optimized] 
     at oracle/net/ns/Packet.receive()V(Unknown Source)[inlined] 
     at oracle/net/ns/DataPacket.receive()V(Unknown Source)[optimized] 
     at oracle/net/ns/NetInputStream.getNextPacket()V(Unknown Source)[optimized] 
     at oracle/net/ns/NetInputStream.read([BII)I(Unknown Source)[inlined] 
     at oracle/net/ns/NetInputStream.read([B)I(Unknown Source)[inlined] 
     at oracle/net/ns/NetInputStream.read()I(Unknown Source)[optimized] 
     at oracle/jdbc/driver/T4CMAREngine.unmarshalUB1()S(T4CMAREngine.java:1099)[optimized] 
<rest of stack omited> 

ऊपर मामले में, आप स्टैक ट्रेस से बता सकते हैं कि JDBC (डेटाबेस) ड्राइवर एक कर रहा है नेटवर्क सॉकेट से पढ़ना अवरुद्ध करना। तो सामान्य अगला कदम यह देखना होगा कि क्या कोई कारण है कि अपेक्षित डेटा में देरी हो सकती है (या यहां तक ​​कि कभी भी नहीं पहुंचती)।उदाहरण के लिए, जिस डेटाबेस सर्वर से हम बात कर रहे हैं, उसे लटकाया जा सकता है, नेटवर्क समस्या हो सकती है जो डाटाबेस की प्रतिक्रिया में देरी (या यहां तक ​​कि छोड़ना) हो सकती है, या कुछ प्रकार के प्रोटोकॉल मेल नहीं हो सकते हैं, जहां दोनों पार्टियां मानती हैं कि यह दूसरी तरफ है बात करने के लिए बारी। दोनों पक्षों पर लॉग फाइलों का विश्लेषण करने से संकेत मिलता है कि क्या हुआ। यदि समस्या पुन: उत्पन्न होती है, तो नेटवर्क ट्रेस एकत्रित करना और WireShark जैसे टूल के साथ इसका विश्लेषण करना भी उपयोगी साबित हो सकता है।

समाधान:

उचित कारण खोजने Afer, तो आप उचित अपवाद हैंडलिंग लिख सकता है और निश्चित रूप से FileInputStream बंद जब हम अवांछित अतिप्रवाह से बचने के लिए यह साथ समाप्त कर लें।

संदर्भ: thread_stuck_at_readbytespinned_writebytespinned