বেশিরভাগ মিডলওয়্যার এপিআই একটি SdvResult অবজেক্ট রিটার্ন করে। সফল হলে, এই অবজেক্টটিতে প্রত্যাশিত ফলাফল অবজেক্টটি থাকে। ব্যর্থ হলে, এই অবজেক্টটিতে একটি SdvStatus অবজেক্ট থাকে, যা একটি অপ্রত্যাশিত আচরণ বা ত্রুটির অবস্থা নির্দেশ করে এবং প্রায়শই একটি এরর কোড দ্বারা চিহ্নিত করা হয়, যেমন Internal , Unavailable , বা DataLoss ।
এই পৃষ্ঠাটি আপনাকে এই ত্রুটি কোডগুলো সমাধান করতে সাহায্য করে।
নিবন্ধন এবং তৈরির ব্যর্থতা সমাধান করুন
সাধারণত যখন আপনি একটি অবৈধ পরিষেবা তৈরি বা নিবন্ধন করার চেষ্টা করেন, তখন নিবন্ধন এবং তৈরির ব্যর্থতা দেখা দেয়।
দ্বিতীয় পরিষেবা তৈরি করা যাবে না
ত্রুটি:
Internal ত্রুটি।
কারণ:
আপনি হুবহু একই সার্ভিস বান্ডেল ইনস্ট্যান্স (নাম এবং ইনস্ট্যান্স আইডি) দুইবার নিবন্ধন করার চেষ্টা করছেন।
সমাধান:
একই সার্ভিস বান্ডেল ইনস্ট্যান্স (নাম এবং ইনস্ট্যান্স আইডি) দুইবার নিবন্ধন করার চেষ্টা করবেন না।
ডুপ্লিকেট সার্ভিস বান্ডেল ডিলিট করা যাচ্ছে না।
ত্রুটি:
Status(-3, EX_ILLEGAL_ARGUMENT)
কারণ:
আপনি এমন একটি নকল সার্ভিস বান্ডেল মুছে ফেলার চেষ্টা করছেন যার কোনো অস্তিত্ব নেই।
সমাধান:
অস্তিত্বহীন কোনো সদৃশ সার্ভিস বান্ডেল মুছে ফেলার চেষ্টা করবেন না।
বার্তা পাঠানোর জন্য কোনো পাবলিশার ইনস্ট্যান্স খুঁজে পাওয়া যাচ্ছে না।
ত্রুটি:
take_publisher() কল করলে none রিটার্ন হয়।
কারণ:
আপনি একই সার্ভিস বান্ডেল ইনস্ট্যান্স থেকে একই ভ্যারিয়েন্টের জন্য take_publisher() ফাংশনটি দুইবার কল করেছেন।
সমাধান:
একই সার্ভিস বান্ডেল ইনস্ট্যান্স থেকে একই ভ্যারিয়েন্টের জন্য take_publisher() দুইবার কল করবেন না।
সাবস্ক্রাইবার, অবজারভার, হিস্ট্রি বা ইনস্ট্যান্টরিডার তৈরি করা যাচ্ছে না।
ত্রুটি:
Unavailable ত্রুটি।
কারণ:
আপনি এমন একজন পাবলিশারের জন্য Subscriber , Observer , History বা InstantReader তৈরি করার চেষ্টা করেছেন যার অস্তিত্ব নেই অথবা যাকে ডি-রেজিস্টার করা হয়েছে।
সমাধান:
কোনো পাবলিশারের জন্য Subscriber , Observer , History বা InstantReader তৈরি করার চেষ্টা করার আগে, পাবলিশারটি বিদ্যমান বা নিবন্ধিত কিনা তা যাচাই করে নিন।
RPC ক্লায়েন্ট তৈরি করা যাচ্ছে না
ত্রুটি:
Unavailable ত্রুটি
কারণ:
আপনি এমন একটি সার্ভার ইউনিট নামের জন্য একটি আরপিসি ক্লায়েন্ট তৈরি করার চেষ্টা করেছেন যা বিদ্যমান নেই বা নিবন্ধিত নয়।
সমাধান:
RPC ক্লায়েন্ট তৈরি করার আগে সার্ভারটি বিদ্যমান এবং নিবন্ধিত আছে কিনা তা যাচাই করুন।
যোগাযোগের ত্রুটি সমাধান করুন
কোনো পরিষেবা চালু হওয়ার পর এবং অন্যান্য পরিষেবার সাথে যোগাযোগ শুরু করার পরে যোগাযোগ ব্যর্থতা ঘটতে পারে।
প্রকাশকের নিবন্ধন বাতিলের সমস্যা সমাধান করুন
যখন কোনো পাবলিশার তার রিডারদের সক্রিয় থাকা অবস্থায় নিবন্ধন বাতিল করে, তখন ত্রুটি ঘটতে পারে।
সাবস্ক্রাইবারের read_next_messages() খালি তালিকা ফেরত দেয়।
ত্রুটি:
read_next_messages() সফল হয় কিন্তু খালি তালিকা ফেরত দেয়।
কারণ:
প্রকাশকের নিবন্ধন বাতিল করা হয়েছে, অথচ তার পাঠকরা সক্রিয় রয়েছে।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি অনুপলব্ধ থাকে, তাহলে পাবলিশারটি ডি-রেজিস্টার্ড হয়ে যায় এবং কোনো নতুন মেসেজ আসে না।
Observer-এর next() অভ্যন্তরীণ ত্রুটি ফেরত দেয়
ত্রুটি:
next() Internal error রিটার্ন করে।
কারণ:
প্রকাশকের নিবন্ধন বাতিল করা হয়েছে, অথচ তার পাঠকরা সক্রিয় রয়েছে।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি অনুপলব্ধ থাকে, তাহলে পাবলিশারটি চলে গেছে এবং কোনো নতুন মেসেজ নেই।
History-এর read_from_history() নতুন বার্তা ফেরত দেয় না।
ত্রুটি:
read_from_history() কোনো নতুন বার্তা ফেরত দেয় না; শুধু পুরোনো বার্তাগুলোই ফেরত দেয়।
কারণ:
প্রকাশকের নিবন্ধন বাতিল করা হয়েছে, অথচ তার পাঠকরা সক্রিয় রয়েছে।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি অনুপলব্ধ থাকে, তাহলে পাবলিশারটি চলে গেছে এবং কোনো নতুন মেসেজ নেই।
InstantReader read_latest_message() অভ্যন্তরীণ ত্রুটি ফেরত দেয়
ত্রুটি:
read_latest_message() Internal error রিটার্ন করে।
কারণ:
প্রকাশকের নিবন্ধন বাতিল করা হয়েছে, অথচ তার পাঠকরা সক্রিয় রয়েছে।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি অনুপলব্ধ থাকে, তাহলে পাবলিশারটি চলে গেছে এবং কোনো নতুন মেসেজ নেই।
খালি মেসেজ কিউ-এর সমস্যা সমাধান করুন
খালি মেসেজ কিউ থেকে পড়ার চেষ্টা করলে ত্রুটি ঘটতে পারে।
সাবস্ক্রাইবারের read_next_messages() একটি খালি তালিকা ফেরত দেয়।
ত্রুটি:
read_next_messages() সফলভাবে একটি খালি তালিকা ফেরত দেয়।
কারণ:
প্রকাশক সক্রিয় আছেন, কিন্তু কোনো বার্তা পাঠাননি।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি পাওয়া যায়, তাহলে পাবলিশারটি সক্রিয় এবং কোনো নতুন মেসেজ নেই।
Observer-এর next() অভ্যন্তরীণ ত্রুটি ফেরত দেয়
ত্রুটি:
next() Internal error রিটার্ন করে।
কারণ:
প্রকাশক সক্রিয় আছেন, কিন্তু কোনো বার্তা পাঠাননি।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি পাওয়া যায়, তাহলে পাবলিশারটি সক্রিয় এবং কোনো নতুন মেসেজ নেই।
History-এর read_from_history() নতুন বার্তা ফেরত দেয় না।
ত্রুটি:
read_from_history() সফলভাবে একটি খালি তালিকা ফেরত দেয়।
কারণ:
প্রকাশক সক্রিয় আছেন, কিন্তু কোনো বার্তা পাঠাননি।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি পাওয়া যায়, তাহলে পাবলিশারটি সক্রিয় এবং কোনো নতুন মেসেজ নেই।
InstantReader read_latest_message() অভ্যন্তরীণ ত্রুটি ফেরত দেয়
ত্রুটি:
read_latest_message() Internal error রিটার্ন করে।
কারণ:
প্রকাশক সক্রিয় আছেন, কিন্তু কোনো বার্তা পাঠাননি।
সমাধান:
অ্যাভেইলেবিলিটি স্ট্রিমের সাথে সাবস্ক্রাইবার বা হিস্ট্রি ব্যবহার করুন। যদি অ্যাভেইলেবিলিটি স্ট্রিমের শেষ মেসেজটি পাওয়া যায়, তাহলে পাবলিশারটি সক্রিয় এবং কোনো নতুন মেসেজ নেই।
বাফার ওভারফ্লো বা ডেটা লসের সমস্যা সমাধান করুন
যখন প্রকাশক পাঠকের গ্রহণ করার ক্ষমতার চেয়ে দ্রুত গতিতে বার্তা পাঠায়, তখন ত্রুটি ঘটতে পারে।
ওভারফ্লোর পরে সাবস্ক্রাইবারের প্রথম রিড ডেটা লস এরর রিটার্ন করে।
ত্রুটি:
read_next_message() DataLoss ত্রুটি ফেরত দেয়।
কারণ:
প্রকাশক পাঠকের গ্রহণ করার ক্ষমতার চেয়েও দ্রুত গতিতে বার্তা পাঠায়।
সমাধান:
ওভারফ্লোর পরে অবজারভারের প্রথম next() কলটি DataLoss ত্রুটি ফেরত দেয়।
ত্রুটি:
next() করলে DataLoss error রিটার্ন হয়।
কারণ:
প্রকাশক পাঠকের গ্রহণ করার ক্ষমতার চেয়েও দ্রুত গতিতে বার্তা পাঠায়।
সমাধান: সম্ভাব্য সমাধানগুলো হলো:
পাবলিশার ধীর গতিতে পাবলিশ করে। উদাহরণস্বরূপ, আপনার কাছে সর্বশেষ মেসেজের টাইমস্ট্যাম্প সহ একটি ভ্যারিয়েবল থাকতে পারে। যদি বর্তমান সময় সর্বশেষ পাবলিশের সময়ের সাথে একটি ডেল্টা যোগ করার পর প্রাপ্ত সময়ের চেয়ে কম হয়, তবে আপনি মেসেজটি পাবলিশ করবেন না। এই পদ্ধতি ব্যবহার করে, প্রতি ডেল্টার জন্য সর্বাধিক একটি মেসেজ পাবলিশ করা হয়।
কনজিউমার অবজারভারের পরিবর্তে একটি
InstantReadঅবজেক্ট ব্যবহার করে। একটিInstantReadঅবজেক্ট ওভারফ্লো এরর রিটার্ন করে না এবং সর্বদা সর্বশেষ মেসেজটি ফেরত দেয়। যদি সর্বশেষ মেসেজটিই আপনার কাছে একমাত্র গুরুত্বপূর্ণ হয়, তাহলে আপনি অবজারভারের পরিবর্তে একটিInstantReadঅবজেক্ট ব্যবহার করতে পারেন।কনজিউমার স্যাম্পলিং প্রয়োগ করে। যদি আপনার সলিউশনে এমন কোনো পাবলিশার (P1) থাকে যা অবজারভার (01)-এর পড়ার গতির চেয়ে দ্রুত মেসেজ পাবলিশ করে, তাহলে পাবলিশিং এবং রিডিং স্পিডের এই পার্থক্য মেটানোর জন্য আপনি একটি নতুন পাবলিশার (P2) এবং অবজারভার (02) তৈরি করতে পারেন।
উদাহরণস্বরূপ, ধরা যাক P1 প্রতি 10 মিলিসেকেন্ডে একটি বার্তা প্রকাশ করে, কিন্তু O1 প্রতি 100 মিলিসেকেন্ডে কেবল একটি বার্তা পড়তে পারে এবং বাকি নয়টি বার্তা বাদ দিয়ে দেয়। এই অসঙ্গতিটি সমাধান করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করে একটি সমাধান তৈরি করুন:
- P1, O2-এর কাছে বার্তা প্রকাশ করে।
- O2 একটি বার্তা পড়ে এবং নয়টি বাদ দেয়।
- O2, P2-এর কাছে একটি পঠিত বার্তা পাঠায়।
- P2, O1-কে একটি পঠিত বার্তা পাঠায়।
- O1 প্রতি দশ সেকেন্ডে একটি বার্তা পড়ে।
নিম্নলিখিত উদাহরণ কোডটি দেখায় কিভাবে এই স্যাম্পলিং সিনারিওটি বাস্তবায়ন করতে হয়:
int discarded_message = 10; while (true) { message m = O2.read_message(); if discarded_message == 10 { discarded_message = 0; P2.publish(m); } else { discarded_message ++; } }
ইতিহাসের পাঠ অসম্পূর্ণ।
ত্রুটি:
হিস্ট্রি কপি করার আগেই মেসেজটি হারিয়ে যায়। পড়ার সময় সরাসরি কোনো ত্রুটির বিজ্ঞপ্তি আসে না।
কারণ:
প্রকাশক পাঠকের গ্রহণ করার ক্ষমতার চেয়েও দ্রুত গতিতে বার্তা পাঠায়।
সমাধান:
InstantReader শুধুমাত্র শেষ বার্তাটি পড়ে।
ত্রুটি:
হিস্ট্রি কপি করার আগেই মেসেজটি হারিয়ে যায়। পড়ার সময় সরাসরি কোনো ত্রুটির বিজ্ঞপ্তি আসে না।
কারণ:
প্রকাশক পাঠকের গ্রহণ করার ক্ষমতার চেয়েও দ্রুত গতিতে বার্তা পাঠায়।
সমাধান:
প্রযোজ্য নয়
RPC ক্লায়েন্ট একটি মেথড কল করে কিন্তু মেথডটি অনুপলব্ধ।
ত্রুটি:
Unavailable ত্রুটির কারণে মেথড কল ব্যর্থ হয়েছে।
কারণ:
SDV সার্ভারের নাম জানে না এবং Unavailable রিটার্ন করে। সার্ভিস ডিসকভারি যদি একটি বৈধ সার্ভারের নাম ফেরত না দেয়, তাহলে মিডলওয়্যার এই ত্রুটিটি রিটার্ন করে।
সমাধান:
একটি সার্ভিস বান্ডেল চালু করুন যা ক্লায়েন্ট কর্তৃক ব্যবহৃতব্য নির্দিষ্ট ইন্টারফেসের জন্য একটি server নির্ধারণ করে।
সার্ভার-সাইড বাস্তবায়ন SdvStatus ত্রুটি ফেরত দেয়
ত্রুটি:
সার্ভার-সাইড ইমপ্লিমেন্টেশনটি একটি SdvResult রিটার্ন করে, যাতে SdvStatusCode::NotFound মতো একটি SdvStatus এরর থাকে। এই এররটি কলিং ক্লায়েন্টের কাছে ফেরত পাঠানো হয়।
কারণ:
SDV এবং ক্লায়েন্ট ও সার্ভারের মধ্যকার যোগাযোগ ব্যবস্থা প্রত্যাশিতভাবেই কাজ করছে, কিন্তু ক্লায়েন্টের করা একটি অনুরোধের ফলে সার্ভারে একটি ত্রুটি দেখা দিয়েছে।
সমাধান:
ক্লায়েন্টের কাছে একটি বৈধ অনুরোধ পাঠান অথবা সার্ভারটিকে এমনভাবে ঠিক করুন যাতে এটি সফলভাবে সেই অনুরোধগুলিতে সাড়া দিতে পারে।