2008-11-06 6 views
11

मेरे पास कई सर्वर प्रक्रियाएं हैं जो एक बार कुछ समय में ग्राहकों से संदेशों का जवाब देती हैं और केवल पढ़ने के लिए लेनदेन करती हैं।हाइबरनेट/जेडीबीसी/माईएसक्यूएल एक दिन के बाद कनेक्शन क्यों छोड़ता है?

सर्वर चल रहे कुछ दिनों के बाद, वे सही तरीके से काम करना बंद कर देते हैं और जब मैं जांचता हूं कि कनेक्शन बंद होने के बारे में संदेशों का पूरा समूह है।

जब मैंने इसे चेक आउट किया, तो यह पता चला कि कुछ प्रकार के विकास मोड में डिफॉल्ट काम से हाइबरनेट, जहां कुछ घंटों के बाद कनेक्शन गिरा दिए जाते हैं, और मैंने कनेक्शन पूलिंग के लिए सी 3 पी का उपयोग शुरू किया।

हालांकि, सी 3 पी के साथ भी, सर्वर को शुरू होने के बाद मुझे 24 घंटे या उससे भी अधिक समस्या मिलती है।

क्या किसी को भी उस समस्या का सामना करना पड़ा है और पता है कि इसे कैसे संबोधित किया जाए? मैं हाइबरनेट को कॉन्फ़िगर करने की जटिलताओं के साथ पर्याप्त परिचित नहीं हूं।

उत्तर

13

माइस्क्लुएल जेडीबीसी चालक 8 घंटे निष्क्रियता के बाद बाहर निकलता है और कनेक्शन छोड़ देता है।

आप अपने जेडीबीसी यूआरएल में autoReconnect=true सेट कर सकते हैं, और इससे डिस्कनेक्ट होने के बाद क्वेरी करने का प्रयास करने पर ड्राइवर फिर से कनेक्ट हो जाता है। लेकिन इसका दुष्प्रभाव है; उदाहरण के लिए सत्र राज्य और लेनदेन को नए कनेक्शन पर बनाए रखा नहीं जा सकता है।

यदि आप autoReconnect का उपयोग करते हैं, तो जेडीबीसी कनेक्शन पुनः स्थापित किया जाता है, लेकिन यह अपवाद प्राप्त करने वाली आपकी क्वेरी को स्वचालित रूप से फिर से निष्पादित नहीं करता है। तो आपको अपने आवेदन में SQLException पकड़ने और प्रश्नों को पुनः प्रयास करने की आवश्यकता है। अधिक जानकारी के लिए

http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html पढ़ें।

+0

धन्यवाद बिल। मैं सत्र स्थिति से चिंतित नहीं हूं क्योंकि मेरे सत्र केवल तभी खोले जाते हैं जब आवश्यक हो और फिर बंद हो; 8 घंटे के लिए एक खुला रखना शायद वैसे भी एक बुरा विचार है। क्या मुझे इसे जेडीबीएल यूआरएल में कॉन्फ़िगर करना चाहिए, या क्या मैं इसे हाइबरनेट गुणों के माध्यम से कॉन्फ़िगर कर सकता हूं? – Uri

+0

मैं इसे जेडीबीसी यूआरएल में कॉन्फ़िगर कर दूंगा। –

+0

'autoReconnect' प्रॉपर्टी का उपयोग करने की अनुशंसा नहीं की जाती है क्योंकि इसमें कुछ अवांछित साइड इफेक्ट्स हैं। इसके बजाय, आपको सर्वर पर 'wait_timeout' को 8 घंटे के डिफ़ॉल्ट से उच्च मान पर बढ़ाना चाहिए। संदर्भ: https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html – nuaavee

1

मैं सुझाव दूंगा कि, लगभग किसी भी ग्राहक/सर्वर सेट-अप में, कनेक्शन की आवश्यकता होने पर कनेक्शन को छोड़ना बुरा विचार है।

मैं विशेष रूप से डीबी 2/जेड कनेक्शन के बारे में सोच रहा हूं लेकिन यह सभी सर्वरों (डेटाबेस और अन्यथा) के लिए समान रूप से लागू होता है। ये कनेक्शन सर्वर पर संसाधनों का उपभोग करते हैं जिनका उपयोग कहीं और किया जा सकता है।

यदि आप कॉर्पोरेट वातावरण में कनेक्शन खोलना चाहते हैं, जहां हजारों ग्राहक डेटाबेस से कनेक्ट होते हैं, तो आप शायद अपने घुटनों पर मेनफ्रेम भी लाएंगे।

मैं सभी कनेक्शन पूलिंग के विचार के लिए हूं, लेकिन व्यक्तिगत सत्रों को हमेशा के लिए खोलने की कोशिश करने के विचार के लिए बहुत कुछ नहीं है।

मेरी सलाह के रूप में निम्नानुसार होगा:

1/अपने कनेक्शन पूल में कनेक्शन के तीन प्रकार है:

  • बंद कर दिया (ताकि अपने पूल नहीं वास्तव में में)।
  • तैयार, जिसका अर्थ खुला है लेकिन ग्राहक द्वारा उपयोग में नहीं है।
  • सक्रिय, जिसका अर्थ क्लाइंट द्वारा उपयोग में किया जाता है।

2/अपने कनेक्शन पूलिंग को कम से कम तैयार कनेक्शन बनाए रखें, न्यूनतम एन और अधिकतम एम एन को शिखर गति के आधार पर समायोजित किया जा सकता है जिस पर आपके ग्राहक कनेक्शन का अनुरोध करते हैं। यदि तैयार कनेक्शन की संख्या शून्य तक गिर जाती है, तो आपको एक बड़ी एन की आवश्यकता होती है।

3/जब कोई ग्राहक कनेक्शन चाहता है, तो उन्हें तैयार लोगों में से एक (इसे सक्रिय करना) दें, फिर एन तैयार होने से कम समय में तुरंत एक नया खोलें (लेकिन ग्राहक इसके लिए प्रतीक्षा न करें पूरा करने के लिए, या आप पूलिंग का लाभ खो देंगे)। यह सुनिश्चित करता है कि कम से कम एन तैयार कनेक्शन हमेशा रहेगा। यदि कोई ग्राहक तैयार होने पर तैयार नहीं होता है, तो आपको एक नया निर्माण करते समय चारों ओर इंतजार करना होगा।

4/जब ग्राहक सक्रिय कनेक्शन के साथ समाप्त होता है, तो एम तैयार तैयार कनेक्शन से कम होने पर इसे तैयार स्थिति में वापस कर दें। अन्यथा इसे बंद करें। यह आपको एम से तैयार कनेक्शन से अधिक होने से रोकता है।

5/समय-समय पर पुराने कनेक्शन को रोकने के लिए तैयार कनेक्शन रीसायकल करें। यदि एन तैयार कनेक्शन से अधिक है, तो बस सबसे पुराना कनेक्शन बंद करें। अन्यथा इसे बंद करें और दूसरा खोलें।

इसका पर्याप्त लाभ और सर्वर कनेक्शन अधिभारित किए बिना आपके कनेक्शन पूल में उपलब्ध युवा कनेक्शन का लाभ है।

+0

सहमत हैं, लेकिन मेरे पास टीएच पूल शून्य से भी कम हो गया है। अगर कोई इसका इस्तेमाल नहीं कर रहा है, तो कनेक्शन क्यों है? –

+1

अपने कनेक्शन पूल के क्लाइंट के लिए विलंबता को कम करने के लिए कुछ खुला छोड़ने का पूरा बिंदु। जब आप एक नया स्थापित करते हैं तो वे चारों ओर इंतजार नहीं करना चाहते हैं। यद्यपि आप एन को शून्य पर सेट करके अपना वांछित प्रभाव प्राप्त कर सकते हैं, मुझे लगता है। – paxdiablo

+0

मेरी समस्या यह है कि मैं हाइबरनेट का उपयोग कर रहा हूं। AFAIK मैं सीधे कनेक्शन को नियंत्रित नहीं कर रहा हूं। सी 3 पीओ या कनेक्शन पूलर या हाइबरनेट स्वयं निष्क्रिय होने पर कनेक्शन बंद नहीं होना चाहिए? – Uri

7

MySQL मूल रूप से 8 घंटे में डिफ़ॉल्ट रूप से टाइमआउट्स।

मुझे एक ही अपवाद मिला & ने 3 व्यस्त दिनों के बाद इस मुद्दे को हल किया। जांचें कि यदि आप Iibernate3 का उपयोग कर रहे हैं तो जांचें। इस संस्करण में कनेक्शन वर्ग नाम का स्पष्ट रूप से उल्लेख करना आवश्यक है। यह भी जांचें कि जार क्लासपाथ में है या नहीं। चेक नीचे दिए गए लिंक में & टिप्पणियां कदम

http://hibernatedb.blogspot.com/2009/05/automatic-reconnect-from-hibernate-to.html

autoReconnect=true

1

मैं thoses लाइनों को जोड़कर मेरी हाइबरनेट विन्यास फाइल बदल निकालें और इसके लिए अब काम करता है:

<property name="connection.autoReconnect">true</property> 
    <property name="connection.autoReconnectForPools">true</property> 
    <property name="connection.is-connection-validation-required">true</property> 

मुझे लगता है कि c3p0 का उपयोग कर कि पूल बेहतर है और पुन: संकलित है लेकिन यह समाधान अब के लिए काम कर रहा है और चींटी की समस्या नहीं पेश करता है।
मैंने 24 घंटे के लिए टॉमकैट ऑन को दिया और कनेक्शन खो गया नहीं था।
कृपया इसे आज़माएं।

संबंधित मुद्दे