Sql सर्वर JDBC कनेक्शन रीसेट त्रुटि: केवल पर अमेज़न EC2

Question

प्रसंग: बादल

हम एक जावा आधारित वेब अनुप्रयोग है कि हम आम तौर पर हमारे अपने सर्वर पर होस्ट की है। हाल ही में हमने एक उदाहरण होस्ट करने के लिए अमेज़ॅन वेब सर्विसेज (एडब्ल्यूएस ईसी 2) क्लाउड का इस्तेमाल किया।

यह "क्लाउड सेटअप" हमारी विशिष्ट "साइट पर" सेटअप से मेल खाता है: ऐप सर्वर के लिए एक सर्वर, डेटाबेस सर्वर के लिए एक और सर्वर। (कई एप्लिकेशन सर्वर एक ही डाटाबेस सर्वर को इंगित)

समस्या इस बादल सेटअप में, हम "सहकर्मी त्रुटियों से कनेक्शन रीसेट" रुक-रुक कर प्राप्त डेटाबेस और JDBC ड्राइवर, जहां पर (प्रतीत होता है) यादृच्छिक अंतराल के बीच और कोडबेस में यादृच्छिक बिंदुओं पर, डेटाबेस कनेक्शन विफल रहता है।

यहाँ लॉग के लिए कुछ त्रुटि अंश हैं

स्टैक ट्रेस उदाहरण 1:

at com.participate.pe.genericdisplay.client.taglib.GenDisplayViewTag.doStartTag(GenDisplayViewTag.java:77) 
    ... 75 more 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed. 
    at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.getMetaData(SQLServerConnection.java:1734) 
    at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:354) 

स्टैक ट्रेस उदाहरण 2

at java.lang.Thread.run(Thread.java:619) 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1355) 
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1532) 
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3274) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4437) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1457) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1416) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1462) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1610) 
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429) 

तकनीकी पर्यावरण

+०१२३५१६४१०

• Jboss 4.2.2.GA (Jboss-वेब 2.0/बिलाव 6)
• MSSQL 2005 2.0 JDBC ड्राइवर

कुछ बिंदुओं

• हम कभी नहीं देखा है में यह समस्या हमारे स्वयं के पर्यावरण (यानी अपने डेटा केंद्र) कई वर्षों के लिए आवेदन चला रहे हैं
• इससे मुझे निष्कर्ष निकाला गया कि "अमेज़ॅन नेटवर्क पर्यावरण के साथ कुछ मजेदार चल रहा है"। मैं कुछ गलत/गायब हो सकता/सकती हूं।
• यह समस्या केवल हमारे आवेदन के साथ होती है। हमारे पास अन्य जावा और PHP अनुप्रयोग हैं जिनके पास यह समस्या नहीं है। अन्य जावा आवेदन एक अलग JDBC ड्राइवर का उपयोग करता है (jtds, afaik)
• यह एक सरल कनेक्शन समयबाह्य की तरह प्रतीत नहीं होता

प्रश्न

-Has किसी को भी इस से पहले देखा है? - अगर यह एक ईसी 2 "ज्ञात मुद्दा" है, तो क्या हम समस्या के चारों ओर अपना रास्ता कॉन्फ़िगर कर सकते हैं (यानी सुनिश्चित करें कि सबकुछ अपने सबनेट या वर्चुअल प्राइवेट क्लाउड (वीपीसी) पर है? -कोई भी जेडीबीसी ड्राइवर सेटिंग्स इस समस्या को दूर करने के लिए?

** अद्यतन ** मैं बढ़ाया और इस प्रश्न पर इनाम वृद्धि हुई

सूचना के अतिरिक्त बिट पर है: दो वर्चुअल सर्वर (डेटाबेस और अनुप्रयोग सर्वर) अलग सबनेट पर थे - एक हॉप अर्थात्। दो सर्वरों के बीच।

गैर-क्लाउड वातावरण में हमारे पास दो शून्य सर्वर "शून्य होप्स" हैं।

हमारे होस्टिंग व्यवस्थापक ने कहा कि हमारे ईसी 2 उदाहरणों के सबनेट पर हमारा कोई नियंत्रण नहीं था। इससे मुझे आश्चर्य हुआ कि वर्चुअल प्राइवेट क्लाउड मदद करेगा। पहले से

धन्यवाद

Answer 1

इस मुद्दे को कम करने के लिए डीआईसीपी/कनेक्शन पूल सुविधाओं पर सावधानी बरतने का एक शब्द - जितना अधिक आप 'testOnBorrow' और अन्य सुविधाओं को सक्षम करते हैं, उतना ही आप विलंबता या अन्य प्रदर्शन परिवर्तन को सिस्टम पर प्रभावित कर सकते हैं। मुझे नहीं पता कि डीबीसीपी अभी भी ऐसा करता है या नहीं, लेकिन कुछ साल पहले यह कनेक्शन की जांच करने के लिए वास्तविक परीक्षण प्रश्न उत्पन्न करेगा - पूर्ण स्टैक, डेटाबेस प्रतिक्रियाएं - न केवल नेटवर्क परत पर। ब्रायन के उपरोक्त लिंक जेडीबीसी कनेक्शन प्रबंधन के लिए आसपास के पुनः प्रयास तर्क पर 2000 के दशक की शुरुआत से भयानक यादें लाता है।

भी हो, यह तुलना में सबूत इकट्ठा और शर्तों का एक विशिष्ट सेट करने के लिए 'मालूम होता है यादृच्छिक' को खत्म करने में वास्तव में जड़ यह पैदा करने के लिए कठिन है, अन्य:

• आप एक Wireshark/PCAP ट्रेस ऊपर फेंक की कोशिश कर सकते , यह तब होता है जब यह होता है, और यह देखने के लिए अमेज़ॅन और माइक्रोसॉफ्ट दोनों को परिणाम भेजते हैं कि वे

• समस्या को अलग करने के लिए आप कुछ परीक्षण harnesses के साथ उपरोक्त कोशिश कर सकते हैं (JMeter परीक्षण समेकन प्राप्त करने के लिए) नेटवर्क कनेक्शन उछाल, वसूली के लिए देखो, आदि

• आप SQL सर्वर के वैकल्पिक संस्करणों को एक SQL सर्वर/जेडीबीसी ड्राइवर बग को छूटने के लिए कोशिश कर सकते हैं जिसे बाद में तय किया गया है।

• डीएनएस कनेक्शन तार में इस्तेमाल किया जाता है, तो इस्तेमाल कर सकते हैं आईपी nslookup मुद्दों

मैं एक एसक्यूएल सर्वर विशेषज्ञ नहीं हूँ, लेकिन अनुसंधान के लिए एक और मार्ग संबंधित उत्पादों के डोमेन के भीतर हो सकता है मान्य करने के लिए संबोधित करते हैं - जैसे देखें कि किसी ने टीएफएस/शेयरपॉइंट (जैसे http://nickhoggard.wordpress.com/2009/12/07/further-experiences-with-tfs-2010-beta-2-on-amazon-ec2/) जैसे

Answer 2

सुनिश्चित नहीं हैं कि इस या संबंधित है, तो है नहीं होंगे। हमने एक ऐप के समान कुछ अनुभव किया जिसे हम ईसी 2 पर्यावरण में चल रहे थे। वही लक्षण, कि डेटाबेस कनेक्शन अंततः बंद हो जाएगा। हम एमएसएसएलएल 1.2 ड्राइवर का उपयोग कर रहे थे। साथ ही, कनेक्शन के साथ देरी या निष्क्रिय समय के बाद आमतौर पर त्रुटियां दिखाई देगी। हमारी धारणा (कभी सिद्ध नहीं) यह थी कि नेटवर्क परत में कुछ कनेक्शन बंद कर रहा था और ग्राहक इसका पता नहीं लगा रहा था, इसलिए यह बासी हो गया।

हम इसके आसपास काम करने में सक्षम थे क्योंकि हम कॉमन्स कनेक्शन पूल का उपयोग कर रहे थे, और पूल विफलता पर कनेक्शन को फिर से बना देता था। हमने अंततः ईसी 2 से आवेदन को स्थानांतरित कर दिया और इस मुद्दे को फिर से नहीं देखा।

Answer 3

मैंने इस मुद्दे को ईसी 2 पर्यावरण और विंडोज़ एज़ूर पर्यावरण दोनों में देखा है। मुझे लगता है कि एक वितरित कंप्यूटिंग पर्यावरण में काम करते समय कनेक्शन रेट्री तर्क को आपके डिजाइन का एक मानक हिस्सा होना चाहिए।

This article एसक्यूएल एज़ूर के लिए है - लेकिन मुझे लगता है कि यह ईसी 2 और सभी ड्राइवरों पर समान रूप से लागू होता है।

Answer 4

मैं यह भी पुष्टि कर सकता हूं कि ऐसा होता है और कम प्राथमिकता जांच को बढ़ा देगा क्योंकि यह उत्पादन महत्वपूर्ण नहीं है।
हमारे उत्पादन सर्वर हमारे डेटा सेंटर में हैं। हम अपने अनुप्रयोगों को चलाने के लिए डेवलपर लैपटॉप का उपयोग करते हैं। एक बार जब हम c3p0 कनेक्शन पूल टाइमआउट और परीक्षण अवधि कॉन्फ़िगर करते हैं, तो इनमें से कोई भी इस समस्या को प्राप्त नहीं करता है (आलेख देखें: http://www.codefin.net/2007/05/hibernate-and-mysql-connection-timeouts.html)।

हालांकि, हमारे पास एक विकास स्टेजिंग सर्वर है जो ईसी 2 में है और यह वास्तव में वहां होता है। अगर मुझे ऐसा लगता है जो काम करने लगता है, तो मैं वापस पिंग करूंगा। इसके अलावा, मैं mysql का उपयोग कर रहा हूँ। मैं देखता हूं कि आप एमएस एसक्यूएल सर्वर का उपयोग कर रहे हैं, इसलिए यह डेटाबेस विक्रेताओं में है।