2015-02-07 3 views
17

क्या Akka.NET में अभिनेताओं के भीतर अपवादों का निपटारा करने के लिए एक मानक पैटर्न है?अभिनेता के भीतर अपवाद कैसे संभालें?

मैंने पर्यवेक्षकों को बनाने के लिए कुछ पैटर्न देखा, लेकिन ऐसा लगता है कि SupervisorStrategy उन चीजों से निपटने का एक तरीका है जिन्हें अभिनेता द्वारा हल नहीं किया जा सकता है।

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

प्रेषक डेटाबेस से कनेक्ट करने वाले इस अभिनेता का अभिभावक नहीं है। क्या मुझे इसे संभालने के लिए पर्यवेक्षक बनाना चाहिए? या क्या मुझे अपने प्राप्त हैंडलर को कोशिश/पकड़ने वाले ब्लॉक में समाहित करना चाहिए और प्रेषकों को कस्टम प्रतिक्रिया के साथ सूचित करने के लिए केवल Tell का उपयोग करना चाहिए जैसे कि यह एक सामान्य संदेश था?

मैं जानता हूँ कि वहाँ एक Failure वर्ग है, लेकिन मुझे यकीन है कि अगर मैं उपयोग करने के लिए कि इस स्थिति के लिए मान लीजिए हूँ नहीं हूँ।

+1

रोजर का जवाब सही है, लेकिन मैं एक विस्तृत स्पष्टीकरण से लिंक करना चाहता हूं कि पदानुक्रमिक पर्यवेक्षण और त्रुटि कर्नेल पैटर्न दोनों Akka.NET में कैसे काम करते हैं: http://petabridge.com/blog/how-actors-recover-from -फेलर-पदानुक्रम और पर्यवेक्षण/ – Aaronontheweb

उत्तर

16

हां वहाँ है। सबसे पहले, हमेशा बाल कलाकारों को खतरनाक काम का प्रतिनिधि दें, उन्हें अपने सभी knifes, लौ फेंकने और ऐसे दे दो। अगर वे दुर्घटनाग्रस्त हो जाते हैं और जलाते हैं, तो आपका राज्य अभी भी बरकरार है और आप नए बच्चों को जन्म दे सकते हैं।

तो पहुंचने योग्य डेटाबेस उदाहरण के लिए; डीबी-संचार अभिनेता को स्पिन करें। फिर आप इस अभिनेता को दो राज्य, डीबी अप और डीबी डाउन कर सकते हैं, इसे एफएसएम के रूप में मॉडल किया जा सकता है या Become/Unbecome का उपयोग किया जा सकता है।

तो जब संदेश आता है और एक डीबी क्वेरी का अनुरोध, अगर चीजों को उड़ाने, डीबी कम्युनिकेटर अभिनेता यह आत्म डीबी नीचे राज्य में डालता है। यदि डीबी-डाउन स्थिति में कोई क्वेरी प्राप्त होती है, तो आप तुरंत Failure ईवेंट के साथ प्रतिक्रिया दे सकते हैं।

तो हम फिर से डीबी-डाउन से डीबी-अप तक कैसे जाते हैं? डीबी-कम्युनिकेटर अभिनेता ScheduleOnce का उपयोग कर स्वयं को पिंग कर सकता है, उदा। प्रत्येक एक्स सेकंड में "चेक डीबीस्टैटस" संदेश स्वयं को पास करें। जब चेकडीबीस्टैटस संदेश प्राप्त होता है, तो आप जांचते हैं कि डीबी फिर से है या नहीं, और यदि ऐसा है, तो आप वापस डीबी-अप स्थिति पर वापस आ जाएंगे।

इस तरह, आप जहां यह उच्च लोड की वजह से जवाब देने में असमर्थ है परिदृश्यों में अपने डीबी बाढ़ नहीं होगा, उस मामले में अधिक लोड जोड़ने केवल बातें बदतर कर देगा। तो इस प्रकार का सर्किट ब्रेकर इसे होने से रोक देगा।

संक्षेप में

तो:

डीबी-अप राज्य में:

एक DBQuery संदेश प्राप्त हुआ है, तो क्वेरी चलाने के लिए प्रयास करें, और प्रतिक्रिया वापस भेज देते हैं। यदि चीजें उड़ती हैं, तो सीधे डीबी-डाउन स्थिति पर जाएं और विफलता ईवेंट के साथ प्रतिक्रिया दें।

डीबी-डाउन स्थिति में: यदि कोई DBQuery संदेश प्राप्त होता है, तो Failure ईवेंट सीधे डी/ओ को स्पर्श करने के साथ प्रतिक्रिया दें। डीबी ऊपर उठने के लिए खुद को हर एक्स सेकंड पिंग करें, और यदि संभव हो तो डीबी-अप स्थिति पर वापस जाएं।

इस परिदृश्य में, आप राज्य पारगमन के लिए किसी भी पर्यवेक्षक का उपयोग नहीं होता है, सामान्य ट्राई/कैच इस से निपटने के लिए पर्याप्त होगा।

इस स्पष्ट चीजों को आशा दें।

+0

हां, यह करता है। सिर्फ एक चीज: एक 'विफलता' घटना है जो सिर्फ एक कस्टम संदेश है जिसे मैं बनाता हूं और 'टेल' के साथ भेजता हूं, या क्या इसके लिए कुछ खास है? – Natan

+0

यह सिर्फ एक आम घटना है, सामान्य प्रयोजनों के लिए "विफलता" घटना में भी बनाया गया है –

+0

क्या मैं सही हूं कि यह डीबी-संचार अभिनेता शीर्ष-स्तरीय अभिनेता होना चाहिए? – Monsignor

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