रस्ट/वास्म रनटाइम विश्वसनीयता के लिए घबराहट और निरस्त पुनर्प्राप्ति दोनों को संभालने की आवश्यकता होती है

वास्म को पहली बार में आसानी से एक पोर्टिंग परत के रूप में माना जा सकता है: कोड को प्रोग्राम किया जा सकता है, पेज चलाया जा सकता है, प्रदर्शन ठीक है, और चीजें लगभग समान लगती हैं। यह वास्तव में कठिन होने लगता है, आमतौर पर डेमो पारित होने के बाद। एक बार जब संपादक, रेंडरर और दस्तावेज़ पार्सर जैसे मॉड्यूल एकल-पृष्ठ प्रयोगों से दीर्घकालिक निवासी रनटाइम में चले जाते हैं, तो दोष मॉडल तुरंत बदल जाएंगे।

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

डेमो पारित होने के बाद, फ़ॉल्ट मॉडल अभी शुरू हुआ है।

एक ही कॉल में क्रैश को समझना मुश्किल नहीं है। एक बटन क्लिक एक वास्म कॉल को ट्रिगर करता है। यदि यह विफल रहता है, तो ऑपरेशन के लिए एक त्रुटि की सूचना दी जाएगी। पृष्ठ को ताज़ा करें और पुनः प्रयास करें। लागत अभी भी नियंत्रणीय है.

समस्या तब होती है जब रनटाइम इंस्टेंस का पुन: उपयोग शुरू करता है। जब एक ही वासम उदाहरण लगातार कई दस्तावेज़ खोलता है, इनपुट घटनाओं के कई दौर प्राप्त करता है, और कई जेएस ब्रिज कॉल से गुजरता है, तो घबराहट और गर्भपात के प्रभाव का दायरा वर्तमान कार्रवाई पर नहीं रुकता है। अपूर्ण विफलता बाद के अनुरोधों को धीमा कर सकती है।

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

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

घबराहट पकड़ी जा सकती है, गर्भपात केवल उदाहरण बदल सकता है।

रस्ट/वास्म में अलग करने वाली सबसे महत्वपूर्ण बात घबराहट और गर्भपात के दो विफलता शब्दार्थ हैं।

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

एक बार जब रनटाइम के दौरान दोनों को एक साथ मिला दिया जाता है, तो बाद की प्रोसेसिंग में निश्चित रूप से समस्याएं उत्पन्न होंगी:

• निगल एक सामान्य अपवाद के रूप में निरस्त हो जाता है, और इंस्टेंस पूल उन वस्तुओं का पुन: उपयोग करना जारी रखेगा जो विश्वसनीयता खो चुके हैं।
• सभी घबराहट के साथ ऐसा व्यवहार करें जैसे कि उदाहरण को नष्ट कर दिया जाना चाहिए, और थ्रूपुट अनावश्यक रूप से कम हो जाएगा
• जेएस होस्ट केवल “कॉल विफल” जानता है, लेकिन यह नहीं जानता कि क्या पुनः प्रयास करना है, उदाहरण खोना है, या वर्तमान सत्र को काट देना है

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

यदि बाइंडिंग परत पुनर्प्राप्ति शब्दार्थ प्रदान नहीं करती है, तो होस्ट परत खराब स्थिति ले लेगी और कार्य को स्वीकार करना जारी रखेगी।

इस प्रकार की समस्या के लिए सबसे खतरनाक स्थान व्यवसाय कोड में नहीं है, बल्कि बाइंडिंग परत में है जिसका “पहले से ही ध्यान रखा गया” लगता है। होस्ट परत अक्सर केवल फेंके गए त्रुटि ऑब्जेक्ट को देखती है और इसे सामान्य कॉल विफलता के रूप में रिकॉर्ड करती है। लॉग वहाँ है और पेज तुरंत क्रैश नहीं होता है, लेकिन हो सकता है कि सिस्टम ने इंस्टेंस के अंदर ख़राब स्थिति छोड़ दी हो।

वास्तव में जिस चीज़ को ठीक करने की आवश्यकता है वह केवल प्रयास/पकड़ने की नहीं है, बल्कि विफलता के बाद की जाने वाली कार्रवाइयों को भी ठीक करने की है। निम्नलिखित के समान तर्क अभी विश्वसनीयता डिजाइन में प्रवेश करना शुरू कर दिया है:

async function runWithRecovery(instance, input) {
  try {
    return await instance.exports.handle(input)
  } catch (error) {
    if (isAbort(error)) {
      pool.replace(instance.id)
    }
    throw error
  }
}

इस कोड का फोकस सिंटैक्स पर नहीं है, बल्कि एक सरल निर्णय पर है: क्या वर्तमान विफलता ने इस उदाहरण को एक अविश्वसनीय वस्तु के रूप में चिह्नित किया है। यदि उत्तर हाँ है, तो पुनर्प्राप्ति कार्रवाई त्रुटियों को फेंकने तक नहीं रुकनी चाहिए, बल्कि उन्मूलन, संसाधन पुनर्निर्माण और अनुरोध प्रवाह में कटौती तक जारी रहनी चाहिए।

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

साझा किए गए उदाहरण पुनर्प्राप्ति समस्या को पूलिंग रणनीति समस्या में बदल देंगे

वासम को वास्तविक उत्पादों में डालने के बाद, शायद ही कभी “पेज बंद होने तक केवल एक उदाहरण” होता है। उदाहरण पूल, वर्कर पूल, या अग्रभूमि दस्तावेज़ और रनटाइम संसाधनों का एक सेट साझा करने वाले पृष्ठभूमि कार्य अधिक सामान्य हैं। इस स्तर पर, घबराहट और गर्भपात की वसूली लागत सीधे पूलिंग रणनीति को फिर से लिखेगी।

यदि इंस्टेंस इनिशियलाइज़ेशन महंगा है, तो सिस्टम स्वाभाविक रूप से जितना संभव हो सके इसका पुन: उपयोग करेगा। लेकिन एक बार पुन: उपयोग स्थापित हो जाने पर, दोष अलगाव को एक साथ उन्नत किया जाना चाहिए:

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

ये ऐसे उत्तर नहीं हैं जो भाषा परत स्वचालित रूप से भेजेगी। वे रनटाइम डिज़ाइन हैं।

इस वजह से, यदि रस्ट/वास्म विश्वसनीयता की चर्चा केवल “क्या घबराहट को पकड़ा जा सकता है?” पर रुक जाती है, तो समस्या को कम आंकना आसान है। जो चीज़ वास्तव में रखरखाव लागत अंतर को बढ़ाती है वह यह है कि क्या इंस्टेंस पूल विफलता के बाद स्पष्ट विश्वास सीमा बनाए रख सकता है।

लागू सीमा का जीवन चक्र से गहरा संबंध है

प्रत्येक वासम परियोजना के लिए पुनर्स्थापना डिज़ाइनों का यह सेट आवश्यक नहीं है।

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

एक बार जब सिस्टम में निम्नलिखित विशेषताएँ आ जाती हैं, तो पुनर्प्राप्ति शब्दार्थ जल्दी से “अनुकूलन आइटम” से “बुनियादी ढांचा आइटम” में बदल जाएगा:

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

जब मोबाइल टीमें मूल क्षमताओं को वेब पर ले जाती हैं, तो इस सीमा का सामना होने की सबसे अधिक संभावना होती है। अलगाव संबंध जो मूल रूप से ऐप प्रक्रिया में डिफ़ॉल्ट रूप से स्थापित किया गया था, उसे अक्सर JS/Wasm होस्ट सीमा तक पहुंचने के बाद फिर से भरना पड़ता था।

Wasm नेटिव कोड के लिए ब्राउज़र में प्रवेश करना आसान बनाता है, लेकिन यह अपने साथ रनटाइम पुनर्प्राप्ति शब्दार्थ नहीं लाता है। जैसे ही सिस्टम इंस्टेंस साझा करना, स्थिति का पुन: उपयोग करना और दीर्घकालिक कॉल स्वीकार करना शुरू करता है, घबराहट और गर्भपात को दो अलग-अलग रनटाइम घटनाओं के रूप में माना जाना चाहिए। पूर्व को इस बात की परवाह है कि वर्तमान कॉल को कैसे समाप्त किया जाए, और बाद वाले को इस बात की परवाह है कि क्या यह उदाहरण पूल में रहना जारी रख सकता है। यदि यह निर्णय पहले नहीं लिया जाता है, तो कोड प्रत्यारोपण जितना अधिक सफल होगा, बाद की विफलताओं से निपटना उतना ही कठिन होगा।