थ्रेड Runnable राज्य दिखा डंप है, लेकिन, काफी समय

Question

हम अपने आवेदन में एक असामान्य समस्या का सामना कर रहे के लिए अपने त्रिशंकु पिछले एक महीने हमारे आवेदन एक अप्राप्य राज्य तक पहुँच में, यह पद आवेदन पुनः आरंभ बरामद किया गया।

पृष्ठभूमि: हमारे आवेदन में कुछ जानकारी लाने के लिए एक डीबी क्वेरी बना देता है और इस डाटाबेस एक अलग नोड पर होस्ट की है।

समस्याग्रस्त मामला: जब थ्रेड डंप का विश्लेषण किया गया था तो हम देखते हैं कि सभी धागे डेटाबेस से डेटा लाने वाले चलने योग्य राज्य में हैं, लेकिन यह 20 मिनट के बाद भी समाप्त नहीं हुआ।

पोस्ट आवेदन पुनः आरंभ सभी धागे की उम्मीद बरामद रूप में। और सीपीयू उपयोग भी सामान्य था। 2: 47 "prio = 3 टीआईडी ​​= 0x0000000007334000 एनआईडी = 0x5f runnable [0xfffffd7fe9f54000] java.lang.Thread.State: oracle.jdbc पर runnable

नीचे धागा डंप

ThreadPool है। driver.T2CStatement.t2cParseExecuteDescribe (मूल निवासी विधि) oracle.jdbc.driver.T2CPreparedStatement.executeForDescribe (T2CPreparedStatement.java:518) पर oracle.jdbc.driver.T2CPreparedStatement.executeForRows (T2CPreparedStatement.java:764) ओरा पर पर

All threads in the same state. 

सवाल:

1. क्या इस राज्य के लिए कारण हो सकता है?
2. इस मामले के तहत कैसे ठीक किया जाए?

Answer 1

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

Answer 2

मूल विधियां हमेशा रननेबल स्थिति में ठीक है (ठीक है, जब तक कि आप मूल विधि से राज्य को बदल नहीं लेते हैं, लेकिन यह गिनती नहीं है)।

विधि आईओ, किसी भी अन्य घटना इंतजार कर रहे हैं या सिर्फ लंबे cpu तीव्र काम ... या अंतहीन लूप पर अवरुद्ध किया जा सकता। आप अपना खुद का चयन कर सकते हैं।

कैसे इस मामले के तहत ठीक करने के लिए?

ऑरैकल से कनेक्शन ड्रॉप करें।

Answer 3

जैसा कि अन्य ने पहले ही उल्लेख किया है, कि देशी विधियां हमेशा चलने योग्य होती हैं, क्योंकि JVM उन्हें नहीं जानता/उनकी परवाह नहीं करता है।

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

पतली ग्राहक का उपयोग करते समय, आप oracle.jdbc.ReadTimeout सेट कर सकते हैं, लेकिन मुझे नहीं पता कि आपके द्वारा उपयोग किए जाने वाले मोटी (ओसीआई) क्लाइंट के लिए यह कैसे करना है, मैं इससे परिचित नहीं हूं।

क्या करना है? अनुसंधान मोटी ojdbc ड्राइवर के लिए रीड टाइमआउट कैसे निर्दिष्ट कर सकते हैं, और कनेक्शन टाइमआउट से संबंधित अपवादों के लिए देखें, जो नेटवर्क समस्याओं को स्पष्ट रूप से सिग्नल करेगा। यदि आप स्रोत बदल सकते हैं, तो आप कॉल को लपेट सकते हैं और सत्र-संबंधित SQLExceptions को पकड़ते समय सत्र को फिर से प्रयास कर सकते हैं।

समस्या को तुरंत हल करने के लिए, मैन्युअल रूप से ओरेकल सर्वर पर कनेक्शन समाप्त करें।

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

Answer 4

क्या सिस्टम या जेवीएम फांसी हो रही है? यदि कॉन्फ़िगर करने योग्य और यदि संभव हो, तो थ्रेड/समांतर कनेक्शन की संख्या को कम करें।

थ्रेड बस आईओ की प्रतीक्षा करते समय सीपीयू चक्र को बर्बाद कर देता है। हां आपका सीपीयू दुर्भाग्यवश उन धागे से व्यस्त रहता है जो डीबी से प्रतिक्रिया की प्रतीक्षा कर रहे हैं।

Answer 5

1. क्या आपका कोड मैन्युअल रूप से लेनदेन को संभालता है? यदि फिर, हो सकता है कि कुछ कोड डेटा बदलने के बाद() नहीं कर पाए। या हो सकता है कि कोई व्यक्ति सीधे पीएलएसक्यूएल या कुछ के माध्यम से डेटा संशोधन क्वेरी चलाता है और प्रतिबद्ध नहीं होता है, और इससे सभी पढ़ने के संचालन को लटका दिया जाता है।

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