2010-02-22 13 views
11

मैं जावा से आ रहा हूं, जहां मैं Runnable एस को ExecutorService पर थ्रेड पूल द्वारा समर्थित करता हूं। जावा में यह बहुत स्पष्ट है कि थ्रेड पूल के आकार में सीमा निर्धारित कैसे करें।स्कैला में कलाकारों का उपयोग करते समय समवर्ती सीमा को कैसे सीमित करें?

मुझे स्कैला कलाकारों का उपयोग करने में दिलचस्पी है, लेकिन मैं अस्पष्टता को सीमित करने के बारे में अस्पष्ट हूं।

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

यदि मैं कतार में नौकरियों को संसाधित करने के लिए कलाकारों का उपयोग कर रहा हूं, तो मैं संसाधित नौकरियों की संख्या को कैसे सीमित कर सकता हूं?

मैं इस दृष्टिकोण के कुछ अलग तरीकों के बारे में सोच सकता हूं; मैं सोच रहा हूं कि क्या कोई समुदाय सर्वोत्तम अभ्यास है, या कम से कम, कुछ स्पष्ट रूप से स्थापित दृष्टिकोण जो स्कैला दुनिया में कुछ हद तक मानक हैं।

एक दृष्टिकोण मैंने सोचा है कि एक समन्वयक अभिनेता है जो नौकरी कतार और नौकरी प्रसंस्करण अभिनेताओं का प्रबंधन करेगा; मुझे लगता है कि यह एक साधारण int फ़ील्ड का उपयोग करके ट्रैक कर सकता है कि वर्तमान में कितनी नौकरियां संसाधित की जा रही हैं। मुझे यकीन है कि उस दृष्टिकोण के साथ कुछ गड़बड़ियां होंगी, हालांकि, जब कोई त्रुटि होती है तो ट्रैक को ट्रैक करना सुनिश्चित होता है ताकि संख्या कम हो सके। यही कारण है कि मैं सोच रहा हूं कि क्या स्कैला पहले से ही एक सरल या अधिक encapsulated दृष्टिकोण प्रदान करता है।

बीटीडब्ल्यू मैंने इस प्रश्न a while ago से पूछने की कोशिश की लेकिन मैंने इसे बुरी तरह से पूछा।

धन्यवाद!

उत्तर

5

आप सिस्टम गुण actors.maxPoolSize और actors.corePoolSize को ओवरराइड कर सकते हैं जो अभिनेता थ्रेड पूल के आकार को सीमित करता है और फिर पूल में कई नौकरियों को फेंक देता है क्योंकि आपके अभिनेता संभाल सकते हैं। आपको लगता है कि आपको थ्रोटल आपकी प्रतिक्रियाओं की आवश्यकता क्यों है?

+1

बहुत उपयोगी, धन्यवाद! मुझे यकीन नहीं है कि मैं _throttle_ शब्द का उपयोग करूंगा, लेकिन किसी भी तरह से, ऐसे समय होते हैं जहां किसी को एक साथ "प्रक्रियाओं" की संख्या को बाधित करने की आवश्यकता होती है क्योंकि वे जो काम करते हैं वह संसाधन-केंद्रित होता है। –

+3

यह दृष्टिकोण वांछित परिणाम नहीं दे सकता है। यह जेवीएम स्मृति से बाहर होने तक नौकरियों को कतारबद्ध करने की अनुमति देगा। कलाकारों द्वारा उपयोग किए जा सकने वाले धागे की संख्या सीमित करने से केवल उन नौकरियों की संख्या सीमित हो जाएगी जो वास्तव में एक साथ निष्पादित की जाती हैं। मैंने कलाकारों की तुलना में तेजी से काम उत्पन्न करके ओओएम त्रुटियों का उत्पादन किया है, इसलिए आपको सावधान रहना होगा। –

+2

मुझे लगता है कि इस दृष्टिकोण का एक नकारात्मक पक्ष यह है कि यह वैश्विक है। कभी-कभी मेरे पास विभिन्न प्रकार की प्रक्रियाएं होती हैं जिन्हें मुझे चलाने की आवश्यकता होती है जिसमें संसाधन उपयोग के विभिन्न स्तर होते हैं - जावा थ्रेड पूल के साथ, मैं आसानी से विभिन्न सेटिंग्स के साथ विभिन्न पूल का उपयोग कर सकता हूं। 'Actors.maxPoolSize' के साथ, मैं केवल सभी कलाकारों के लिए एक ही संख्या का उपयोग कर सकता हूं, क्योंकि वे सभी एक ही थ्रेड पूल द्वारा संचालित हैं, है ना? –

6

मैं आपको वास्तव में स्कैला के लिए वैकल्पिक अभिनेता कार्यान्वयन अक्का को देखने के लिए प्रोत्साहित करता हूं।

http://www.akkasource.org

अक्का पहले से ही एक JAX-आरएस [1] एकीकरण है और आप इस्तेमाल कर सकते हैं कि संगीत समारोह में एक LoadBalancer साथ [2] रुके कितनी गतिविधियां parallell में किया जा सकता:

[1 ] http://doc.akkasource.org/rest [2] http://github.com/jboner/akka/blob/master/akka-patterns/src/main/scala/Patterns.scala

+0

दिलचस्प, मैं इसे देख लूंगा, धन्यवाद! –

3

आपको वास्तव में यहां दो समस्याएं हैं।

पहला अभिनेता द्वारा नियंत्रित धागे पूल को नियंत्रित करता है। यह सिस्टम प्रॉपर्टी एक्टर्स.मैक्सपूलसाइज सेट करके किया जा सकता है।

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

प्रत्येक कार्यकर्ता धागा कार्यों का एक डेक्यू बनाए रखता है। डेक्यू को एक सरणी के रूप में कार्यान्वित किया जाता है कि कार्यकर्ता थ्रेड गतिशील रूप से कुछ अधिकतम आकार तक बढ़ाएगा। 2.7 मेंएक्स कतार स्वयं काफी बड़ी हो सकती है और मैंने देखा है कि समवर्ती धागे के साथ संयुक्त होने पर स्मृति त्रुटियों से बाहर ट्रिगर होता है। अधिकतम डेक्यू आकार छोटा 2.8 है। डेक्यू भी भर सकता है।

इस समस्या को संबोधित करने के लिए आपको यह नियंत्रित करने की आवश्यकता है कि आप कितने कार्य उत्पन्न करते हैं, जिसका शायद आपके द्वारा उल्लिखित कुछ प्रकार के समन्वयक का अर्थ है। मुझे इस समस्या का सामना करना पड़ा है जब अभिनेता जो डेटा प्रोसेसिंग पाइपलाइन शुरू करते हैं, वे बाद में पाइपलाइन में बहुत तेज हैं। क्रमशः उस प्रक्रिया को नियंत्रित करने के लिए, जिसमें आमतौर पर चेन पिंग में कलाकारों के चेन में प्रत्येक एक्स संदेश श्रृंखला में कलाकार होते हैं, और पहले एक्स संदेशों के बाद चेन स्टॉप में पहले होते हैं और पिंग बैक के लिए प्रतीक्षा करते हैं। आप इसे अधिक केंद्रीकृत समन्वयक के साथ भी कर सकते हैं।

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