عیب یابی خرابی های میان افزار API، عیب یابی خرابی های میان افزار API

اکثر رابط‌های برنامه‌نویسی میان‌افزار (middleware APIs) یک شیء SdvResult برمی‌گردانند. در صورت موفقیت، این شیء حاوی شیء نتیجه مورد انتظار است. در صورت شکست، این شیء حاوی یک شیء SdvStatus است که نشان‌دهنده یک رفتار غیرمنتظره یا وضعیت خطا است که اغلب با یک کد خطا مانند Internal ، Unavailable یا DataLoss شناسایی می‌شود.

این صفحه به شما کمک می‌کند تا این کدهای خطا را عیب‌یابی کنید.

عیب‌یابی خطاهای ثبت و ایجاد

معمولاً هنگام تلاش برای ایجاد یا ثبت یک سرویس نامعتبر، خطاهای ثبت و ایجاد رخ می‌دهد.

نمی‌توان سرویس دوم ایجاد کرد

خطا:

خطای Internal .

علت:

شما در حال تلاش برای ثبت دقیقاً یک نمونه بسته سرویس (نام و شناسه نمونه) دو بار هستید.

رفع اشکال:

سعی نکنید دقیقاً یک نمونه بسته سرویس (نام و شناسه نمونه) را دو بار ثبت کنید.

نمی‌توان بسته سرویس تکراری را حذف کرد

خطا:

Status(-3, EX_ILLEGAL_ARGUMENT)

علت:

شما در حال تلاش برای حذف یک بسته سرویس تکراری هستید که وجود ندارد.

رفع اشکال:

سعی نکنید بسته‌ی سرویس تکراری که وجود ندارد را حذف کنید.

نمی‌توان نمونه ناشر را برای ارسال پیام بازیابی کرد

خطا:

فراخوانی تابع take_publisher() none را برنمی‌گرداند.

علت:

شما دو بار تابع take_publisher() را برای یک نوع داده از یک نمونه بسته سرویس فراخوانی کرده‌اید.

رفع اشکال:

تابع take_publisher() برای یک متغیر از یک نمونه بسته سرویس دو بار فراخوانی نکنید.

نمی‌توانم یک مشترک، ناظر، تاریخچه یا InstantReader ایجاد کنم

خطا:

خطای Unavailable .

علت:

شما سعی کردید یک Subscriber ، Observer ، History یا InstantReader برای ناشری ایجاد کنید که وجود ندارد یا ثبت آن لغو شده است.

رفع اشکال:

قبل از تلاش برای ایجاد یک Subscriber ، Observer ، History یا InstantReader برای ناشر، تأیید کنید که ناشر وجود دارد یا ثبت شده است.

نمی‌توان کلاینت RPC ایجاد کرد

خطا:

خطای Unavailable

علت:

شما سعی کردید یک کلاینت RPC برای نام واحد سروری که وجود ندارد یا ثبت نشده است، ایجاد کنید.

رفع اشکال:

قبل از ایجاد کلاینت RPC، تأیید کنید که سرور وجود دارد و ثبت شده است.

عیب‌یابی خطاهای ارتباطی

ممکن است پس از اجرای یک سرویس و شروع ارتباط با سایر سرویس‌ها، خطاهای ارتباطی رخ دهد.

عیب‌یابی لغو ثبت ناشر

خطاهایی ممکن است رخ دهد زمانی که یک ناشر در حالی که خوانندگانش هنوز فعال هستند، ثبت نام را لغو می‌کند.

تابع read_next_messages() مشترک، لیست‌های خالی برمی‌گرداند.

خطا:

read_next_messages() موفق می‌شود اما لیست‌های خالی را برمی‌گرداند.

علت:

ناشر در حالی که خوانندگانش فعال هستند، از ثبت خارج می‌شود.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس نباشد، ناشر لغو ثبت شده است و هیچ پیام جدیدی وجود ندارد.

تابع next() در تابع ناظر، خطای داخلی برمی‌گرداند.

خطا:

next() خطای Internal را برمی‌گرداند.

علت:

ناشر در حالی که خوانندگانش فعال هستند، از ثبت خارج می‌شود.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس نباشد، ناشر از بین رفته است و هیچ پیام جدیدی وجود ندارد.

تابع read_from_history() در تاریخچه، پیام‌های جدید را برنمی‌گرداند.

خطا:

read_from_history() هیچ پیام جدیدی را بر نمی‌گرداند؛ فقط پیام‌های قدیمی‌تر را برمی‌گرداند.

علت:

ناشر در حالی که خوانندگانش فعال هستند، از ثبت خارج می‌شود.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس نباشد، ناشر از بین رفته است و هیچ پیام جدیدی وجود ندارد.

تابع ()reader read_latest_message خطای داخلی برمی‌گرداند.

خطا:

read_latest_message() خطای Internal را برمی‌گرداند.

علت:

ناشر در حالی که خوانندگانش فعال هستند، از ثبت خارج می‌شود.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس نباشد، ناشر از بین رفته است و هیچ پیام جدیدی وجود ندارد.

عیب‌یابی صف پیام‌های خالی

هنگام تلاش برای خواندن از یک صف پیام خالی، ممکن است خطاهایی رخ دهد.

تابع read_next_messages()‎ مربوط به مشترکین، یک لیست خالی برمی‌گرداند.

خطا:

read_next_messages() با موفقیت لیست خالی را برمی‌گرداند.

علت:

ناشر فعال است، اما پیامی ارسال نکرده است.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس باشد، ناشر فعال است و هیچ پیام جدیدی وجود ندارد.

تابع next() در تابع ناظر، خطای داخلی برمی‌گرداند.

خطا:

next() خطای Internal را برمی‌گرداند.

علت:

ناشر فعال است، اما پیامی ارسال نکرده است.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس باشد، ناشر فعال است و هیچ پیام جدیدی وجود ندارد.

تابع read_from_history() در تاریخچه، پیام‌های جدید را برنمی‌گرداند.

خطا:

read_from_history() با موفقیت لیست خالی را برمی‌گرداند.

علت:

ناشر فعال است، اما پیامی ارسال نکرده است.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس باشد، ناشر فعال است و هیچ پیام جدیدی وجود ندارد.

تابع ()reader read_latest_message خطای داخلی برمی‌گرداند.

خطا:

read_latest_message() خطای Internal را برمی‌گرداند.

علت:

ناشر فعال است، اما پیامی ارسال نکرده است.

رفع اشکال:

از یک مشترک یا سابقه با یک جریان در دسترس بودن استفاده کنید. اگر آخرین پیام جریان در دسترس بودن در دسترس باشد، ناشر فعال است و هیچ پیام جدیدی وجود ندارد.

عیب‌یابی سرریز بافر یا از دست رفتن داده‌ها

خطاها می‌توانند زمانی رخ دهند که ناشر پیام‌ها را با سرعتی بیشتر از آنچه خواننده می‌تواند آنها را مصرف کند، ارسال کند.

اولین خواندن مشترک پس از سرریز، خطای DataLoss را برمی‌گرداند

خطا:

read_next_message() خطای DataLoss را برمی‌گرداند.

علت:

ناشر پیام‌ها را با سرعتی بیشتر از آنچه خواننده بتواند آنها را مصرف کند، ارسال می‌کند.

رفع اشکال:

اولین تابع next() در ناظر پس از سرریز، خطای DataLoss را برمی‌گرداند.

خطا:

next() خطای DataLoss را برمی‌گرداند.

علت:

ناشر پیام‌ها را با سرعتی بیشتر از آنچه خواننده بتواند آنها را مصرف کند، ارسال می‌کند.

راه حل: راه حل های بالقوه عبارتند از:

  • ناشر با سرعت کمتری منتشر می‌کند. برای مثال، ممکن است متغیری با برچسب زمانی آخرین پیام داشته باشید. اگر زمان فعلی کمتر از آخرین زمان انتشار به علاوه یک دلتا باشد، پیام را منتشر نمی‌کنید. با استفاده از این مکانیسم، حداکثر یک پیام به ازای هر دلتا منتشر می‌شود.

  • مصرف‌کننده به جای یک ناظر از یک شیء InstantRead استفاده می‌کند. یک شیء InstantRead خطاهای سرریز را برنمی‌گرداند و همیشه آخرین پیام را برمی‌گرداند. اگر آخرین پیام تنها پیامی است که برای شما مهم است، می‌توانید به جای یک ناظر از یک شیء InstantRead استفاده کنید.

  • مصرف‌کننده نمونه‌گیری را پیاده‌سازی می‌کند. اگر راه‌حل شما یک ناشر (P1) دارد که پیام‌ها را سریع‌تر از آنچه ناظر (01) می‌تواند بخواند منتشر می‌کند، می‌توانید یک ناشر (P2) و ناظر (02) جدید ایجاد کنید تا تفاوت در سرعت انتشار و خواندن را در نظر بگیرید.

    برای مثال، فرض کنید P1 هر 10 میلی‌ثانیه یک پیام منتشر می‌کند، اما O1 می‌تواند فقط یک پیام را در هر 100 میلی‌ثانیه بخواند و نه پیام باقی‌مانده را حذف کند. برای حل این اختلاف، راه‌حلی ایجاد کنید که این مراحل را دنبال کند:

    1. P1 پیام‌هایی را برای O2 منتشر می‌کند.
    2. O2 یک پیام می‌خواند و نه پیام را رها می‌کند.
    3. O2 پیام تک‌خوانی شده را به P2 ارسال می‌کند.
    4. P2 پیام تک‌خوانی شده را به O1 ارسال می‌کند.
    5. 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 حاوی خطای SdvStatus ، مانند SdvStatusCode::NotFound ، را برمی‌گرداند. این خطا به کلاینت فراخواننده ارسال می‌شود.

علت:

SDV و سیستم ارتباطی بین کلاینت و سرور طبق انتظار کار می‌کنند، اما کلاینت درخواستی ارسال کرده که باعث ایجاد خطا در سرور می‌شود.

رفع اشکال:

یک درخواست معتبر به کلاینت ارسال کنید یا سرور را طوری تنظیم کنید که با موفقیت به آن درخواست‌ها پاسخ دهد.