মরিচা/ওয়াসম রানটাইম নির্ভরযোগ্যতার জন্য প্যানিক এবং গর্ভপাত পুনরুদ্ধার উভয়ই পরিচালনা করা প্রয়োজন

Wasm সহজেই প্রথমে একটি পোর্টিং স্তর হিসাবে গণ্য করা যেতে পারে: কোডটি প্রোগ্রাম করা যেতে পারে, পৃষ্ঠাটি চালানো যেতে পারে, কর্মক্ষমতা ঠিক আছে এবং জিনিসগুলি একই রকম বলে মনে হচ্ছে। এটি সত্যিই কঠিন হতে শুরু করে, সাধারণত ডেমো পাস করার পরে। একবার মডিউল যেমন সম্পাদক, রেন্ডারার এবং ডকুমেন্ট পার্সার একক-পৃষ্ঠা পরীক্ষা থেকে দীর্ঘমেয়াদী আবাসিক রানটাইমে চলে গেলে, ফল্ট মডেলগুলি অবিলম্বে পরিবর্তিত হবে।

এই সময়ে, প্যানিক এবং গর্ভপাত ভাষা স্তরে আর ব্যতিক্রম শাখা নয়। তারা যা সিদ্ধান্ত নেয় তা হল: এই উদাহরণটি পরবর্তী কাজ গ্রহণ করা চালিয়ে যেতে পারে কিনা, মেমরির অবস্থা দূষিত কিনা, হোস্ট স্তরটি অবিলম্বে দৃষ্টান্তটি বাতিল করা উচিত কিনা এবং উদাহরণ পুলটি পূরণ করা দরকার কিনা। যখন মোবাইল টিম একটি কার্নেলকে সরিয়ে নিয়ে যায় যা দীর্ঘদিন ধরে নেটিভ কন্টেনারে চলছে, তখন পরিবর্তনের এই স্তরটি সবচেয়ে সহজে অবমূল্যায়ন করা হয়।

ডেমো পাস হওয়ার পর, ফল্ট মডেল সবে শুরু হয়েছে।

একক কলে ক্র্যাশ বোঝা কঠিন নয়। একটি বোতাম ক্লিক একটি Wasm কল ট্রিগার করে। এটি ব্যর্থ হলে, অপারেশনের জন্য একটি ত্রুটি রিপোর্ট করা হবে। পৃষ্ঠাটি রিফ্রেশ করুন এবং আবার চেষ্টা করুন। খরচ এখনও নিয়ন্ত্রণযোগ্য।

রানটাইম দৃষ্টান্তগুলি পুনরায় ব্যবহার করা শুরু করার পরে সমস্যাটি ঘটে। যখন একই Wasm দৃষ্টান্ত ক্রমাগত একাধিক নথি খোলে, একাধিক রাউন্ড ইনপুট ইভেন্ট গ্রহণ করে এবং একাধিক জেএস ব্রিজ কলের মধ্য দিয়ে যায়, তখন আতঙ্ক এবং গর্ভপাতের প্রভাবের সুযোগ বর্তমান অ্যাকশনে আর থামে না। একটি অসম্পূর্ণ ব্যর্থতা পরবর্তী অনুরোধগুলি টেনে আনতে পারে।

এই ধরনের ঝুঁকি প্রায়ই প্রথম দিনে প্রকাশ করা হয় না. প্রথম পর্যায়ে, আপনি সাধারণত শুধুমাত্র বিক্ষিপ্ত ত্রুটি প্রতিবেদনগুলি দেখতে পান: মাঝে মাঝে রেন্ডারিং ব্যর্থতা, একটি নির্দিষ্ট রপ্তানি আটকে থাকে এবং একটি নির্দিষ্ট নথি বন্ধ এবং পুনরায় খোলার পরে একটি ভুল অবস্থায় থাকে। আপনি যদি আরও পরীক্ষা করেন, ক্লুগুলি ধীরে ধীরে একই ঘটনাতে একত্রিত হবে: যদিও ব্যর্থতা একটি কল চেইনে ঘটেছে, ক্ষতিটি ভাগ করা উদাহরণে রয়ে গেছে।

এই মুহুর্তে, আলোচনার ফোকাস আর “মরিচা কোড আতঙ্কিত হবে কিনা” নয়, বরং “আতঙ্কের পরে পরবর্তী কলটি পরিবেশন চালিয়ে যাওয়ার জন্য এই রানটাইমটি যোগ্য কিনা”।

আতঙ্ক ধরা যেতে পারে, গর্ভপাত শুধুমাত্র ঘটনা পরিবর্তন করতে পারে।

মরিচা/ওয়াসম-এ আলাদা করার সবচেয়ে গুরুত্বপূর্ণ বিষয় হল প্যানিক এবং অ্যাবোর্টের দুটি ব্যর্থ শব্দার্থ।

আতঙ্কেরও প্রতিষ্ঠিত সীমানা বরাবর ফিরে যাওয়ার সুযোগ রয়েছে। যতক্ষণ বাইন্ডিং লেয়ার এবং হোস্ট লেয়ার পুনরুদ্ধার পদ্ধতিতে অগ্রিম সম্মত হয়, বর্তমান কলটি ব্যর্থ হতে পারে এবং উদাহরণের অন্যান্য অবস্থাও বজায় রাখা যেতে পারে। গর্ভপাত মোটেও যাওয়ার উপায় নয়। এর মানে হল যে বর্তমান মৃত্যুদন্ড একটি অপুনরুদ্ধারযোগ্য অবস্থায় পৌঁছেছে। আপনি যদি অনুরোধগুলি পাওয়ার জন্য একই উদাহরণ ব্যবহার করা চালিয়ে যান, আপনি মূলত বাজি ধরছেন যে মেমরি এবং সংস্থানগুলি অর্ধেক ক্ষতিগ্রস্ত হবে না।

রানটাইমের সময় দুটি একসাথে মিশে গেলে, পরবর্তী প্রক্রিয়াকরণে সমস্যাগুলি অবশ্যই ঘটবে:

• একটি স্বাভাবিক ব্যতিক্রম হিসাবে swallow abort, এবং ইন্সট্যান্স পুল বিশ্বাসযোগ্যতা হারিয়ে ফেলা বস্তুর পুনরায় ব্যবহার করতে থাকবে।
• সমস্ত আতঙ্কের সাথে এমনভাবে আচরণ করুন যেন উদাহরণটি অবশ্যই ধ্বংস করা উচিত এবং থ্রুপুট অপ্রয়োজনীয়ভাবে হ্রাস করা হবে
• JS হোস্ট শুধুমাত্র “কল ব্যর্থ হয়েছে” জানে, কিন্তু পুনরায় চেষ্টা করতে হবে, উদাহরণ হারাতে হবে বা বর্তমান সেশনটি বন্ধ করতে হবে কিনা তা জানে না

এটি Wasm রানটাইম নির্ভরযোগ্যতা সম্পর্কে সবচেয়ে বাস্তবসম্মত জিনিস: পরবর্তী বিচ্ছিন্নতা এবং সময়সূচী বাস্তবায়নের আগে পুনরুদ্ধারের শব্দার্থবিদ্যাকে প্রথমে সংজ্ঞায়িত করতে হবে।

যদি বাইন্ডিং লেয়ার রিকভারি শব্দার্থ প্রদান না করে, হোস্ট লেয়ারটি খারাপ অবস্থায় নিয়ে যাবে এবং কাজটি গ্রহণ করতে থাকবে।

এই ধরণের সমস্যার জন্য সবচেয়ে বিপজ্জনক জায়গাটি ব্যবসায়িক কোডে নয়, তবে বাঁধাই স্তরে যা “ইতিমধ্যে যত্ন নেওয়া হয়েছে” বলে মনে হয়। হোস্ট স্তর প্রায়শই শুধুমাত্র একটি নিক্ষিপ্ত ত্রুটি বস্তু দেখে এবং এটি একটি সাধারণ কল ব্যর্থতা হিসাবে রেকর্ড করে। লগটি আছে এবং পৃষ্ঠাটি অবিলম্বে ক্র্যাশ হয় না, তবে সিস্টেমটি উদাহরণের ভিতরে খারাপ অবস্থা ছেড়ে থাকতে পারে।

আসলে যা ঠিক করা দরকার তা হল শুধু চেষ্টা/ক্যাচ নয়, ব্যর্থতার পর হ্যান্ডলিং অ্যাকশন। নিম্নলিখিত অনুরূপ যুক্তি সবেমাত্র নির্ভরযোগ্যতা নকশা প্রবেশ করতে শুরু করেছে:

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

এই কোডের ফোকাস সিনট্যাক্সের উপর নয়, একটি সাধারণ রায়ের উপর: বর্তমান ব্যর্থতা এই উদাহরণটিকে অবিশ্বস্ত বস্তু হিসাবে চিহ্নিত করেছে কিনা। যদি উত্তর হ্যাঁ হয়, তবে পুনরুদ্ধারের ক্রিয়াটি ত্রুটিগুলি ছুঁড়ে দেওয়া বন্ধ করা উচিত নয়, তবে দৃষ্টান্ত নির্মূল, সংস্থান পুনর্গঠন এবং প্রবাহ কাটার অনুরোধ করা চালিয়ে যাওয়া উচিত।

যতক্ষণ না এই স্তরটি স্পষ্টভাবে সংজ্ঞায়িত করা হয় না, ততক্ষণ সিস্টেমটি ত্রুটিগুলি পরিচালনা করছে বলে মনে হবে, তবে এটি আসলে যা করছে তা হল একটি সম্ভাব্য দূষিত রানটাইমকে উত্পাদন পথে ফিরিয়ে আনা।

শেয়ার করা দৃষ্টান্তগুলি পুনরুদ্ধার সমস্যাটিকে পুলিং কৌশল সমস্যায় পরিণত করবে

Wasm বাস্তব পণ্যে রাখার পরে, “পৃষ্ঠাটি বন্ধ না হওয়া পর্যন্ত একটি উদাহরণ” খুব কমই আছে। ইনস্ট্যান্স পুল, কর্মী পুল, বা ফোরগ্রাউন্ড ডকুমেন্ট এবং ব্যাকগ্রাউন্ড টাস্কগুলি রানটাইম সংস্থানগুলির একটি সেট ভাগ করে নেওয়া আরও সাধারণ। এই পর্যায়ে, আতঙ্ক এবং গর্ভপাতের পুনরুদ্ধারের খরচ সরাসরি পুলিং কৌশল পুনর্লিখন করবে।

যদি ইনস্ট্যান্স ইনিশিয়ালাইজেশন ব্যয়বহুল হয়, তবে সিস্টেম স্বাভাবিকভাবেই যতটা সম্ভব পুনরায় ব্যবহার করার প্রবণতা দেখাবে। কিন্তু একবার পুনঃব্যবহার প্রতিষ্ঠিত হলে, ফল্ট আইসোলেশনকে একই সাথে আপগ্রেড করতে হবে:

• কোন রাজ্যগুলি শুধুমাত্র একটি একক কলে হ্যাং করা যেতে পারে, এবং ব্যর্থ হওয়ার পরে কলের সাথে বাতিল করা হবে৷
• কোন ক্যাশগুলিকে কল জুড়ে ধরে রাখার অনুমতি দেওয়া হয় এবং কোন ক্যাশেগুলি একবার বাতিলের সম্মুখীন হলে সম্পূর্ণরূপে বাতিল করতে হবে
• দৃষ্টান্ত প্রতিস্থাপন করার পরে, সারিবদ্ধ কাজগুলি কীভাবে স্থানান্তরিত হবে? আবার চেষ্টা করলে কি দুবার পার্শ্বপ্রতিক্রিয়া হবে?

এগুলি উত্তর নয় যে ভাষা স্তর স্বয়ংক্রিয়ভাবে পাঠাবে। তারা রানটাইম ডিজাইন.

এই কারণে, যদি মরিচা/ওয়াসম নির্ভরযোগ্যতার আলোচনা শুধুমাত্র “আতঙ্ক ধরা যায়?” এ থেমে যায়, তাহলে সমস্যাটিকে অবমূল্যায়ন করা সহজ। যা সত্যিই রক্ষণাবেক্ষণ খরচের ব্যবধানকে প্রশস্ত করে তা হল ইনস্ট্যান্স পুল ব্যর্থতার পরে একটি স্পষ্ট বিশ্বাসের সীমানা বজায় রাখতে পারে কিনা।

প্রযোজ্য সীমানা জীবনচক্রের সাথে দৃঢ়ভাবে সম্পর্কিত

প্রতিটি Wasm প্রকল্পের জন্য এই পুনরুদ্ধার ডিজাইনের সেট প্রয়োজন হয় না।

যদি মডিউলটি শুধুমাত্র একটি এককালীন অফলাইন টুল হয়, বা পৃষ্ঠাটি ধ্বংস হয়ে গেলে সম্পূর্ণ উদাহরণটি পুনর্ব্যবহার করা হয়, তাহলে প্যানিক এবং গর্ভপাতের মধ্যে পার্থক্যটি এখনও বিদ্যমান থাকবে, তবে পুনরুদ্ধারের সুবিধা অনেক কম হবে। পৃষ্ঠাটি সরাসরি রিফ্রেশ করা এবং সরাসরি টাস্ক পুনরায় চালানোর জন্য এটি প্রায়শই যথেষ্ট।

সিস্টেমের নিম্নলিখিত বৈশিষ্ট্যগুলি হয়ে গেলে, পুনরুদ্ধারের শব্দার্থবিদ্যা দ্রুত একটি “অপ্টিমাইজেশন আইটেম” থেকে একটি “অবকাঠামো আইটেম”-এ পরিবর্তিত হবে:

• উদাহরণটি দীর্ঘ সময়ের জন্য থাকে এবং একক পৃষ্ঠার জীবনচক্রের সাথে একত্রে ধ্বংস হয় না
• একই উদাহরণ ক্রমাগত কলের একাধিক রাউন্ড গ্রহণ করে
• হোস্টিং স্তরকে স্টার্টআপ সময় এবং থ্রুপুটের বিনিময়ে পুলিং ব্যবহার করতে হবে
• ব্যর্থতার পরে সেশন স্টেট, ক্যাশে স্টেট এবং সারিবদ্ধ কাজগুলি সুরক্ষিত করুন

যখন মোবাইল দলগুলি নেটিভ ক্ষমতাগুলিকে ওয়েবে নিয়ে যায়, তখন এই সীমার সম্মুখীন হওয়ার সম্ভাবনা সবচেয়ে বেশি। যে বিচ্ছিন্নতা সম্পর্কটি মূলত অ্যাপ প্রক্রিয়ায় ডিফল্টরূপে প্রতিষ্ঠিত হয়েছিল তা প্রায়শই JS/Wasm হোস্ট সীমানায় পৌঁছানোর পরে আবার পূরণ করতে হয়।

Wasm নেটিভ কোডের জন্য ব্রাউজারে প্রবেশ করা সহজ করে তোলে, কিন্তু এটি রানটাইম পুনরুদ্ধারের শব্দার্থকে এর সাথে নিয়ে আসে না। যত তাড়াতাড়ি সিস্টেম দৃষ্টান্তগুলি ভাগ করা শুরু করে, রাষ্ট্র পুনঃব্যবহার করে এবং দীর্ঘমেয়াদী কলগুলি গ্রহণ করে, আতঙ্ক এবং বাতিলকে দুটি ভিন্ন রানটাইম ইভেন্ট হিসাবে বিবেচনা করা উচিত। প্রাক্তনটি বর্তমান কলটি কীভাবে শেষ করা যায় সে সম্পর্কে চিন্তা করে এবং পরবর্তীটি এই উদাহরণটি পুলে থাকতে পারে কিনা তা নিয়ে চিন্তা করে। যদি এই বিচারটি প্রথমে করা না হয়, কোড ট্রান্সপ্লান্টেশন যত বেশি সফল হবে, পরবর্তী ব্যর্থতাগুলি মোকাবেলা করা তত বেশি কঠিন হবে।