2015-11-25 5 views
12

मैं Vert.x के साथ खेल रहा हूं और थ्रेड/कनेक्शन मॉडल के विपरीत ईवेंट लूप के आधार पर सर्वर पर काफी नया हूं।Vert.x इवेंट लूप - यह असीमित कैसे है?

public void start(Future<Void> fut) { 
    vertx 
     .createHttpServer() 
     .requestHandler(r -> { 
      LocalDateTime start = LocalDateTime.now(); 
      System.out.println("Request received - "+start.format(DateTimeFormatter.ISO_DATE_TIME)); 
      final MyModel model = new MyModel(); 
      try { 

       for(int i=0;i<10000000;i++){ 
        //some simple operation 
       } 

       model.data = start.format(DateTimeFormatter.ISO_DATE_TIME) +" - "+LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME); 

      } catch (Exception e1) { 
       // TODO Auto-generated catch block 
       e1.printStackTrace(); 
      } 

      r.response().end(
        new Gson().toJson(model) 
       ); 
     }) 
     .listen(4568, result -> { 
      if (result.succeeded()) { 
      fut.complete(); 
      } else { 
      fut.fail(result.cause()); 
      } 
     }); 
    System.out.println("Server started .."); 
    } 
  • मैं सिर्फ एक लंबी चलने वाली अनुरोध हैंडलर अनुकरण करने के लिए समझने के लिए कैसे इस मॉडल काम करता है कोशिश कर रहा हूँ।
  • मैंने जो देखा है, वह मेरा पहला अनुरोध पूरा होने तक तथाकथित ईवेंट लूप अवरुद्ध है। जो कुछ भी समय लगता है, उसके बाद का अनुरोध तब तक नहीं किया जाता जब तक कि पिछले एक पूरा नहीं हो जाता।
  • जाहिर है, मैं यहां एक टुकड़ा खो रहा हूं और यही वह सवाल है जो मेरे पास है।

संपादित जवाब अब तक के आधार पर:

सभी अनुरोधों
  1. स्वीकार नहीं कर रहा है अतुल्यकालिक माना जाता? यदि कोई नया कनेक्शन केवल तभी स्वीकार किया जा सकता है जब पिछले व्यक्ति को बंद कर दिया गया हो, तो यह एसिंक कैसे है?
    • मान लें कि एक सामान्य अनुरोध 100 एमएस से 1 सेकंड (अनुरोध की तरह और प्रकृति के आधार पर) के बीच कहीं भी लेता है। तो इसका मतलब है, इवेंट लूप पिछले अनुरोध खत्म होने तक एक नया कनेक्शन स्वीकार नहीं कर सकता है (भले ही इसकी हवाएं एक सेकंड में हों)। और यदि मैं प्रोग्रामर के रूप में इन सभी के माध्यम से सोचना चाहता हूं और ऐसे अनुरोध हैंडलर को कार्यकर्ता थ्रेड पर धक्का देना है, तो यह थ्रेड/कनेक्शन मॉडल से अलग कैसे होता है?
    • मैं यह समझने की कोशिश कर रहा हूं कि यह मॉडल पारंपरिक थ्रेड/कॉन सर्वर मॉडल से बेहतर कैसे है? मान लें कि कोई I/O op या नहीं है I/O op को समकालिक रूप से संभाला जाता है? यह c10k समस्या को हल भी करता है, जब यह सभी समवर्ती अनुरोधों को समानांतर रूप से प्रारंभ नहीं कर सकता है और पिछले एक को समाप्त होने तक प्रतीक्षा करना है?
  2. भले ही मैं इन सभी परिचालनों को एक कार्यकर्ता थ्रेड (पूल) में धक्का देने का फैसला करता हूं, फिर भी मैं वही समस्या पर वापस आ गया हूं? धागे के बीच संदर्भ स्विचिंग? संपादन और एक इनाम

    • पूरी तरह से समझ में नहीं आ कैसे इस मॉडल अतुल्यकालिक का दावा किया है के लिए इस सवाल का टॉपिंग।
    • वर्ट.एक्स में एसिंक जेडीबीसी क्लाइंट है (असिनक्रोनस कीवर्ड है) जिसे मैंने आरएक्सजेवा के साथ अनुकूलित करने की कोशिश की।
    • यहाँ एक कोड नमूना (प्रासंगिक अंश)

    server.requestStream() है toObservable() की सदस्यता लें (अनुरोध -।।> {

     LocalDateTime start = LocalDateTime.now(); 
         System.out.println("Request for " + req.absoluteURI() +" received - " +start.format(DateTimeFormatter.ISO_DATE_TIME)); 
         jdbc.getConnectionObservable().subscribe(
           conn -> { 
    
            // Now chain some statements using flatmap composition 
            Observable<ResultSet> resa = conn.queryObservable("SELECT * FROM CALL_OPTION WHERE UNDERLYING='NIFTY'"); 
            // Subscribe to the final result 
            resa.subscribe(resultSet -> { 
    
             req.response().end(resultSet.getRows().toString()); 
             System.out.println("Request for " + req.absoluteURI() +" Ended - " +LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME)); 
            }, err -> { 
             System.out.println("Database problem"); 
             err.printStackTrace(); 
            }); 
           }, 
    
           // Could not connect 
           err -> { 
            err.printStackTrace(); 
           } 
           ); 
    
    }); 
    server.listen(4568); 
    
    • चयन क्वेरी वहाँ 3 सेकंड लेता है लगभग पूरी तालिका डंप वापस करने के लिए।
    • जब मैं समवर्ती अनुरोधों को आग लगाता हूं (केवल 2 के साथ प्रयास किया जाता है), तो मुझे लगता है कि दूसरा अनुरोध पूरी तरह से पूरा करने के लिए पहले इंतजार कर रहा है।
    • यदि जेडीबीसी चयन एसिंक्रोनस है, तो क्या यह उचित उम्मीद नहीं है कि फ्रेमवर्क दूसरे कनेक्शन को संभालने के लिए है, जबकि यह कुछ भी वापस करने के लिए चुनिंदा क्वेरी के लिए इंतजार कर रहा है।
+0

टीएलडीआर: लंबे समय तक चलने वाले कार्यों के लिए रणनीति पृष्ठभूमि थ्रेडपूल (क्लासिक मल्टीथ्रेडिंग) पर स्विच करना है जो ब्लॉकिंग से बचने के लिए ईवेंट लूप के समान थ्रेड का उपयोग नहीं कर रहा है। –

उत्तर

2

प्रसंस्करण इंजन के इन प्रकार में, आप एसिंक्रोनस रूप से निष्पादित संचालन करने के लिए लंबे समय से चल रहा कार्य चालू अपेक्षा की जाती है और इन, ऐसा करने के लिए एक पद्धति है ताकि महत्वपूर्ण धागा के रूप में जल्दी के रूप में पूरा कर सकते हैं संभव है और एक और काम करने के लिए वापस आते हैं। यानी आईओ ऑपरेशन किए जाने पर आपको वापस कॉल करने के लिए किसी भी आईओ ऑपरेशंस को फ्रेमवर्क में पास किया जाता है।

ढांचा इस अर्थ में असीमित है कि यह आपको इन असीमित कार्यों का उत्पादन और चलाने का समर्थन करता है, लेकिन यह आपके कोड को तुल्यकालिक रूप से समकालिक रूप से परिवर्तित नहीं करता है।

4

यह असीमित कैसे है? इसका जवाब आपके सवाल में है ही

क्या मैंने देखा गया है तथाकथित घटना पाश अवरुद्ध है जब तक मेरी पहले अनुरोध के पूरे होने है। जो भी कम समय लेता है, बाद में अनुरोध जब तक पिछले एक पूरा करता

विचार कर रहा है के बजाय प्रत्येक HTTP अनुरोध सेवा करने के लिए एक नया होने के लिए, एक ही धागा प्रयोग किया जाता है पर कार्रवाई नहीं की है जो आप अपने लंबी चलने से अवरोधित कर दिया है कार्य।

इवेंट लूप का लक्ष्य एक थ्रेड से दूसरे थ्रेड में संदर्भ स्विचिंग में शामिल समय को बचाने और आईओ/नेटवर्क गतिविधियों का उपयोग करते समय आदर्श CPU समय का उपयोग करना है। यदि आपके अनुरोध को संभालने के दौरान इसे अन्य आईओ/नेटवर्क ऑपरेशन करना था, उदाहरण के लिए: उस समय के दौरान एक दूरस्थ मोंगोडीबी उदाहरण से डेटा प्राप्त करना आपके थ्रेड को अवरुद्ध नहीं किया जाएगा और इसके बजाय एक अन्य अनुरोध उसी थ्रेड द्वारा परोसा जाएगा जो आदर्श उपयोग केस है इवेंट लूप मॉडल (यह ध्यान में रखते हुए कि आपके सर्वर पर आने वाले समवर्ती अनुरोध हैं)।

यदि आपके पास लंबे समय तक चलने वाले कार्य हैं जिनमें नेटवर्क/आईओ ऑपरेशन शामिल नहीं है, तो आपको इसके बजाय थ्रेड पूल का उपयोग करने पर विचार करना चाहिए, यदि आप अपना मुख्य ईवेंट लूप थ्रेड स्वयं ब्लॉक करते हैं तो अन्य अनुरोधों में देरी होगी। यानी लंबे समय तक चलने वाले कार्यों के लिए आप उत्तरदायी होने के लिए सर्वर के लिए संदर्भ स्विचिंग की कीमत का भुगतान करना ठीक है।

संपादित: तरह से एक सर्वर संभाल कर सकते हैं अनुरोध भिन्न हो सकते हैं:

1) प्रत्येक आवक अनुरोध के लिए एक नया धागा (इस मॉडल में संदर्भ स्विचिंग उच्च होगा स्पोन और वहाँ स्पॉन की अतिरिक्त लागत है एक नया धागा हर बार)

2) अनुरोध (धागा के एक ही सेट अप पंक्तिबद्ध हो जाता अनुरोध और अतिरिक्त अनुरोध का उत्तर देने के लिए इस्तेमाल किया जाएगा)

3) एक घटना पाश का उपयोग करें (एकल सर्वर के लिए एक थ्रेड पूल का प्रयोग करें सभी अनुरोधों के लिए धागा। नगण्य con पाठ स्विचिंग। क्योंकि कुछ थ्रेड चल रहे होंगे उदाहरण के लिए: इनकमिंग अनुरोधों को कतारबद्ध करने के लिए)

सभी संदर्भ स्विचिंग खराब नहीं है, इसे एप्लिकेशन सर्वर को उत्तरदायी रखना आवश्यक है, लेकिन, बहुत अधिक संदर्भ स्विचिंग समस्या हो सकती है यदि समवर्ती अनुरोधों की संख्या बहुत अधिक है (लगभग 10k से अधिक)। मैं सुझाव है कि आप पढ़ने के लिए C10K article

मान लें एक विशिष्ट अनुरोध 1 सेकंड (आधारित तरह की और अनुरोध की प्रकृति पर) के लिए कहीं भी 100 के बीच एमएस लेता है आप और अधिक विस्तार से समझने के लिए चाहते हैं।तो इसका मतलब है, इवेंट लूप पिछले अनुरोध को समाप्त होने तक एक नया कनेक्शन स्वीकार नहीं कर सकता है (यहां तक ​​कि यदि इसकी दूसरी सेकंड में हवाएं हों)।

यदि आपको बड़ी संख्या में समवर्ती अनुरोधों (10k से अधिक) का जवाब देने की आवश्यकता है तो मैं लंबे समय तक चलने वाले ऑपरेशन के रूप में 500ms से अधिक मानता हूं। दूसरा, जैसा कि मैंने कहा था कि कुछ धागे/संदर्भ स्विचिंग शामिल हैं उदाहरण: इनकमिंग अनुरोधों को कतारबद्ध करने के लिए, लेकिन, थ्रेड के बीच संदर्भ स्विचिंग बहुत कम हो जाएगी क्योंकि एक समय में बहुत कम थ्रेड होंगे। तीसरा, यदि पहले अनुरोध को हल करने में शामिल नेटवर्क/आईओ ऑपरेशन है तो दूसरे अनुरोध को हल करने से पहले हल करने का मौका मिलेगा, यह वह जगह है जहां यह मॉडल अच्छी तरह से खेलता है।

और मैं तो एक प्रोग्रामर के रूप तो यह कैसे एक धागा/कनेक्शन मॉडल से भिन्न क्यों है, इन सभी के माध्यम से लगता है और एक कार्यकर्ता धागा करने के लिए इस तरह का अनुरोध संचालकों पुश करने के लिए है?

प्रोग्रामर के रूप में आप कैसे दोनों परिदृश्य यानी लंबे साथ और बिना नेटवर्क/आईओ आपरेशन आपरेशन चल रहा है के तहत कुशल अपने आवेदन बनाने के लिए पर एक कॉल कर सकते Vertx, आप धागे और घटना पाश की सर्वश्रेष्ठ देने के लिए कोशिश कर रहा है, इसलिए ।

मैं यह समझने की कोशिश कर रहा हूं कि यह मॉडल पारंपरिक थ्रेड/कॉन सर्वर मॉडल से बेहतर कैसे है? मान लें कि कोई I/O op या नहीं है I/O op को समकालिक रूप से संभाला जाता है? यह c10k समस्या को हल भी करता है, जब यह सभी समवर्ती अनुरोधों को समानांतर रूप से प्रारंभ नहीं कर सकता है और को पिछले एक टर्मिने तक प्रतीक्षा करनी है?

उपरोक्त स्पष्टीकरण को इसका उत्तर देना चाहिए।

भले ही मैं इन सभी परिचालनों को एक कार्यकर्ता थ्रेड (पूल) पर धक्का देने का फैसला करता हूं, तो मैं वही समस्या पर वापस आ गया हूं? संदर्भ धागे के बीच स्विचिंग?

जैसा कि मैंने कहा, दोनों पेशेवर हैं और विपक्ष और वर्क्स आपको मॉडल दोनों देता है और आपके उपयोग के मामले में आपको यह चुनना होगा कि आपके परिदृश्य के लिए आदर्श क्या है।

+0

मैंने प्रतिक्रियाओं के आधार पर प्रश्न संपादित किया है। मैं समझता हूं कि लंबे समय तक चलने वाले कार्यों को एक कार्यकर्ता धागे पर धक्का दिया जाना चाहिए। आप एक लंबे समय तक चलने वाले ऑपरेशन को कैसे परिभाषित करते हैं। यदि एक सामान्य अनुरोध समाप्त होने के लिए एक सेकंड लेता है, तो यह मेरे प्रकार के आवेदन के लिए लंबे समय तक नहीं चल रहा है, लेकिन साथ ही ईवेंट लूप एक ही समय में आने वाले 10 समवर्ती अनुरोधों को संभालने वाला नहीं है। यह एक बेहतर मॉडल कैसा है? – user378101

+0

कृपया मेरा संपादन – prasun

15

वर्ट.एक्स इवेंट लूप वास्तव में कई प्लेटफार्मों पर शास्त्रीय घटना पाश मौजूद है। और निश्चित रूप से, अधिकांश स्पष्टीकरण और दस्तावेज़ Node.js के लिए मिल सकते हैं, क्योंकि यह इस आर्किटेक्चर पैटर्न के आधार पर सबसे लोकप्रिय ढांचा है। Node.js इवेंट लूप के तहत यांत्रिकी के एक या कम अच्छे explanation पर नज़र डालें। Vert.x tutorial में "हमें कॉल न करें, हम आपको कॉल करेंगे" और "वर्टिकल्स" के बीच भी अच्छी व्याख्या है। आपके अपडेट के लिए

संपादित करें:

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

मान लें कि एक सामान्य अनुरोध 100 एमएस से 1 सेकंड (अनुरोध की तरह और प्रकृति के आधार पर) के बीच कहीं भी लेता है।

उस स्थिति में आपके अनुरोध में कुछ गणना महंगे हिस्सों या आईओ तक पहुंच है - ईवेंट लूप में आपका कोड इस परिचालन के परिणाम के लिए इंतजार नहीं करना चाहिए।

मैं यह समझने की कोशिश कर रहा हूं कि यह मॉडल पारंपरिक थ्रेड/कॉन सर्वर मॉडल से बेहतर कैसे है? मान लें कि कोई I/O op नहीं है या सभी I/O ऑप को असीमित रूप से संभाला जाता है?

जब आपके पास बहुत अधिक समवर्ती अनुरोध और पारंपरिक प्रोग्रामिंग मॉडल है, तो आप प्रत्येक अनुरोध के लिए धागा बना देंगे। यह धागा क्या करेगा? वे ज्यादातर आईओ संचालन के लिए इंतजार करेंगे (उदाहरण के लिए, डेटाबेस से परिणाम)। यह संसाधनों का अपशिष्ट है। हमारे इवेंट लूप मॉडल में आपके पास एक मुख्य धागा है जो लंबे कार्यों के लिए संचालन और कार्यकर्ता धागे की आवंटित राशि निर्धारित करता है। + इनमें से कोई भी कर्मचारी वास्तव में प्रतिक्रिया की प्रतीक्षा नहीं करता है, वे आईओ परिणाम की प्रतीक्षा करते समय बस एक और कोड निष्पादित कर सकते हैं (इसे वर्तमान में प्रगति पर आईओ नौकरियों की कॉलबैक या आवधिक जांच स्थिति के रूप में लागू किया जा सकता है)। मैं आपको यह समझने के लिए Java NIO और जावा एनआईओ 2 के माध्यम से जाने की सलाह दूंगा कि यह एसिंक आईओ वास्तव में ढांचे के अंदर कैसे कार्यान्वित किया जा सकता है। Green threads भी बहुत संबंधित अवधारणा है, यह समझने के लिए अच्छा होगा। ग्रीन थ्रेड्स और कोरआउट्स छायांकित घटना लूप का एक प्रकार है, जो एक ही चीज़ को प्राप्त करने की कोशिश कर रहा है - कम धागे, क्योंकि हम सिस्टम धागे का पुन: उपयोग कर सकते हैं जबकि हरे रंग के धागे कुछ के लिए इंतजार कर रहे हैं।

यह सी 10 के समस्या को कैसे हल करता है, जब यह समान समवर्ती अनुरोधों को समानांतर शुरू नहीं कर सकता है और पिछले एक टर्मिने तक प्रतीक्षा करना है?

निश्चित रूप से हम पिछले अनुरोध की प्रतिक्रिया भेजने के लिए मुख्य धागे में प्रतीक्षा नहीं करते हैं। अनुरोध प्राप्त करें, अनुसूची लंबी/आईओ कार्य निष्पादन, अगले अनुरोध अनुसूची।

भले ही मैं इन सभी परिचालनों को एक कार्यकर्ता थ्रेड (पूल) में धक्का देने का फैसला करता हूं, फिर भी मैं वही समस्या पर वापस आ गया हूं? धागे के बीच संदर्भ स्विचिंग?

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

के बारे में अपने कोड, मैं तुम्हें प्रदर्शित करने के लिए के लिए है कि सब कुछ काम करता है के रूप में उम्मीद एक नमूना project बनाया:

public class MyFirstVerticle extends AbstractVerticle { 

    @Override 
    public void start(Future<Void> fut) { 
     JDBCClient client = JDBCClient.createShared(vertx, new JsonObject() 
       .put("url", "jdbc:hsqldb:mem:test?shutdown=true") 
       .put("driver_class", "org.hsqldb.jdbcDriver") 
       .put("max_pool_size", 30)); 


     client.getConnection(conn -> { 
      if (conn.failed()) {throw new RuntimeException(conn.cause());} 
      final SQLConnection connection = conn.result(); 

      // create a table 
      connection.execute("create table test(id int primary key, name varchar(255))", create -> { 
       if (create.failed()) {throw new RuntimeException(create.cause());} 
      }); 
     }); 

     vertx 
      .createHttpServer() 
      .requestHandler(r -> { 
       int requestId = new Random().nextInt(); 
       System.out.println("Request " + requestId + " received"); 
        client.getConnection(conn -> { 
         if (conn.failed()) {throw new RuntimeException(conn.cause());} 

         final SQLConnection connection = conn.result(); 

         connection.execute("insert into test values ('" + requestId + "', 'World')", insert -> { 
          // query some data with arguments 
          connection 
           .queryWithParams("select * from test where id = ?", new JsonArray().add(requestId), rs -> { 
            connection.close(done -> {if (done.failed()) {throw new RuntimeException(done.cause());}}); 
            System.out.println("Result " + requestId + " returned"); 
            r.response().end("Hello"); 
           }); 
         }); 
        }); 
      }) 
      .listen(8080, result -> { 
       if (result.succeeded()) { 
        fut.complete(); 
       } else { 
        fut.fail(result.cause()); 
       } 
      }); 
    } 
} 

@RunWith(VertxUnitRunner.class) 
public class MyFirstVerticleTest { 

    private Vertx vertx; 

    @Before 
    public void setUp(TestContext context) { 
    vertx = Vertx.vertx(); 
    vertx.deployVerticle(MyFirstVerticle.class.getName(), 
     context.asyncAssertSuccess()); 
    } 

    @After 
    public void tearDown(TestContext context) { 
    vertx.close(context.asyncAssertSuccess()); 
    } 

    @Test 
    public void testMyApplication(TestContext context) { 
     for (int i = 0; i < 10; i++) { 
      final Async async = context.async(); 
      vertx.createHttpClient().getNow(8080, "localhost", "/", 
          response -> response.handler(body -> { 
           context.assertTrue(body.toString().contains("Hello")); 
           async.complete(); 
          }) 
     ); 
    } 
    } 
} 

आउटपुट:

Request 1412761034 received 
Request -1781489277 received 
Request 1008255692 received 
Request -853002509 received 
Request -919489429 received 
Request 1902219940 received 
Request -2141153291 received 
Request 1144684415 received 
Request -1409053630 received 
Request -546435082 received 
Result 1412761034 returned 
Result -1781489277 returned 
Result 1008255692 returned 
Result -853002509 returned 
Result -919489429 returned 
Result 1902219940 returned 
Result -2141153291 returned 
Result 1144684415 returned 
Result -1409053630 returned 
Result -546435082 returned 

तो, हम अनुरोध स्वीकार - डेटाबेस के लिए अनुसूची अनुरोध, अगले अनुरोध करने के लिए जाना है, हम सभी ओ उपभोग करते हैं उन्हें एफ और केवल प्रत्येक अनुरोध के लिए प्रतिक्रिया भेजें जब सब कुछ डेटाबेस के साथ किया जाता है।

अपने कोड नमूने के बारे में मुझे दो संभावित समस्याएं दिखाई देती हैं - सबसे पहले, ऐसा लगता है कि आप close() कनेक्शन नहीं हैं, जो इसे पूल में वापस करना महत्वपूर्ण है। दूसरा, आप पूल कैसे कॉन्फ़िगर किया गया है? यदि केवल एक ही मुफ्त कनेक्शन है - तो यह अनुरोध इस कनेक्शन का इंतजार करने के क्रमबद्ध होगा।

मैं आपको अनुरोध करता हूं कि आप दोनों अनुरोधों के लिए टाइमस्टैम्प के कुछ प्रिंटिंग को जोड़ने के लिए कहां से क्रमबद्ध करें। आप ऐसा कुछ डालते हैं जो ईवेंट लूप अवरुद्ध करने में कॉल करता है। या ... जांचें कि आप अपने परीक्षण में समानांतर में अनुरोध भेजते हैं। पिछले के बाद प्रतिक्रिया प्राप्त करने के बाद अगला नहीं।

+0

पूल आकार = 30 देखें और मैंने टाइमस्टैम्प को उत्सर्जित करने के लिए लॉग रखे हैं। रीक प्राप्त होने पर प्रारंभ समय को आउटपुट करने के लिए एक लॉग और अन्य जब रिकक पूरा हो जाता है। मैं जो देखता हूं वह है कि प्रत्येक अनुरोध को पूरा करने में लगभग 4 सेकंड लगते हैं और प्रत्येक अनुरोध पिछले एक के लिए हवाओं के लिए इंतजार कर रहा है। Vert.x प्रलेखन के अनुसार, उनका जेडीबीसी रैपर एसिंक है कि यह एसक्यूएल परिणामों को वापस करने की प्रतीक्षा नहीं करता है लेकिन जो मैं देखता हूं वह एक तुल्यकालिक व्यवहार है। यह घटना लूप पर वापस जाने से पहले परिणाम लौटाए जाने तक प्रतीक्षा करता है। – user378101

+0

@ user378101 नमूना [प्रोजेक्ट] (https://github.com/Spikhalskiy/stackoverflow/tree/master/33909011) पर एक नज़र डालें। आप बस वहां परीक्षण शुरू कर सकते हैं और आउटपुट पर एक नज़र डालें। सब कुछ अपेक्षित के रूप में काम करता है और जेडीबीसी क्लाइंट वास्तव में निश्चित रूप से असीमित है। उत्तर देने के लिए विवरण जोड़ा गया। –

+0

offcourse मैं समानांतर में अनुरोध भेज रहा हूं। मैं उस गूंगा नहीं हूँ: - अपने नमूना कोड का प्रयास करेंगे और थोड़ी देर में वापस आ जाएगा। – user378101

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