פתרון בעיות שקשורות לכשלים ב-API של תוכנת ביניים

רוב ממשקי ה-API של תוכנת הביניים מחזירים אובייקט SdvResult. אם הפעולה בוצעה ללא שגיאות, האובייקט הזה מכיל את אובייקט התוצאה הצפוי. במקרה של כשל, האובייקט הזה מכיל אובייקט SdvStatus, שמציין התנהגות לא צפויה או מצב שגיאה, שלרוב מזוהה על ידי קוד שגיאה, כמו Internal, Unavailable או DataLoss.

בדף הזה מוסבר איך לפתור בעיות שקשורות לקודי השגיאה האלה.

פתרון בעיות שקשורות לרישום ולכשלים ביצירה

כשלים ברישום וביצירה מתרחשים בדרך כלל כשמנסים ליצור או לרשום שירות לא תקין.

אי אפשר ליצור שירות שני

שגיאה:

Internal שגיאה.

הסיבה:

ניסית לרשום את אותו מופע בדיוק של חבילת שירותים (שם ומזהה מופע) פעמיים.

פתרון:

אל תנסו לרשום את אותו מופע של חבילת שירותים (שם ומזהה מופע) פעמיים.

אי אפשר למחוק חבילת שירות כפולה

שגיאה:

Status(-3, EX_ILLEGAL_ARGUMENT)

הסיבה:

ניסית למחוק חבילת שירותים כפולה שלא קיימת.

פתרון:

אל תנסו למחוק חבילת שירות כפולה שלא קיימת.

לא ניתן לאחזר מופע של בעל תוכן דיגיטלי לשליחת הודעות

שגיאה:

השיחה למספר take_publisher() חוזרת למספר none.

הסיבה:

הפעלת את השיטה take_publisher() פעמיים לאותו וריאנט מאותו מופע של חבילת שירות.

פתרון:

אל תפעילו את take_publisher() פעמיים לאותה וריאציה מאותו מופע של חבילת שירותים.

אי אפשר ליצור Subscriber,‏ Observer,‏ History או InstantReader

שגיאה:

Unavailable שגיאה.

הסיבה:

ניסית ליצור Subscriber, Observer, History או InstantReader לבעל תוכן דיגיטלי שלא קיים או שבוטלה ההרשמה שלו.

פתרון:

לפני שמנסים ליצור Subscriber, Observer, History או InstantReader עבור בעל האתר, צריך לוודא שהוא קיים או רשום.

אי אפשר ליצור לקוח RPC

שגיאה:

שגיאה אחת (Unavailable)

הסיבה:

ניסית ליצור לקוח RPC עבור שם יחידת שרת שלא קיים או שלא רשום.

פתרון:

לפני שיוצרים את לקוח ה-RPC, צריך לוודא שהשרת קיים ורשום.

פתרון בעיות שקשורות לכשלים בתקשורת

יכול להיות שיהיו כשלים בתקשורת אחרי ששירות מופעל ומתחיל לתקשר עם שירותים אחרים.

פתרון בעיות שקשורות לביטול הרישום של יצרן תוכן

שגיאות יכולות להתרחש כשבעל תוכן דיגיטלי מבטל את ההרשמה בזמן שהקוראים שלו עדיין פעילים.

הפונקציה read_next_messages() של המנוי מחזירה רשימות ריקות

שגיאה:

הפעולה read_next_messages() מצליחה אבל מחזירה רשימות ריקות.

הסיבה:

הסרת ההרשמה של בעל התוכן הדיגיטלי מתבצעת בזמן שהקוראים שלו פעילים.

פתרון:

משתמשים במנוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות לא זמינה, המפרסם מבטל את הרישום ואין הודעות חדשות.

הפונקציה next() של Observer מחזירה שגיאה פנימית

שגיאה:

next() החזרות Internal שגיאה.

הסיבה:

הסרת ההרשמה של בעל התוכן הדיגיטלי מתבצעת בזמן שהקוראים שלו פעילים.

פתרון:

משתמשים במינוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות לא זמינה, המשמעות היא שהמפרסם לא פעיל ואין הודעות חדשות.

הפונקציה read_from_history() של ההיסטוריה לא מחזירה הודעות חדשות

שגיאה:

‫read_from_history() לא מחזיר הודעות חדשות, אלא רק הודעות ישנות יותר.

הסיבה:

הסרת ההרשמה של בעל התוכן הדיגיטלי מתבצעת בזמן שהקוראים שלו פעילים.

פתרון:

משתמשים במינוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות לא זמינה, המשמעות היא שהמפרסם לא פעיל ואין הודעות חדשות.

הפונקציה InstantReader read_latest_message()‎ מחזירה שגיאה פנימית

שגיאה:

read_latest_message() החזרות Internal שגיאה.

הסיבה:

הסרת ההרשמה של בעל התוכן הדיגיטלי מתבצעת בזמן שהקוראים שלו פעילים.

פתרון:

משתמשים במינוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות לא זמינה, המשמעות היא שהמפרסם לא פעיל ואין הודעות חדשות.

פתרון בעיות בתור הודעות ריק

יכולות להיות שגיאות בניסיון לקרוא מתור הודעות ריק.

הפונקציה read_next_messages() של המנוי מחזירה רשימה ריקה

שגיאה:

‫read_next_messages() מחזירה רשימה ריקה.

הסיבה:

המוציא לאור פעיל, אבל לא שלח הודעות.

פתרון:

משתמשים במנוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות זמינה, סימן שהמוציא לאור פעיל ואין הודעות חדשות.

הפונקציה next() של Observer מחזירה שגיאה פנימית

שגיאה:

next() החזרות Internal שגיאה.

הסיבה:

המוציא לאור פעיל, אבל לא שלח הודעות.

פתרון:

משתמשים במנוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות זמינה, סימן שהמוציא לאור פעיל ואין הודעות חדשות.

הפונקציה read_from_history() של ההיסטוריה לא מחזירה הודעות חדשות

שגיאה:

‫read_from_history() מחזירה רשימה ריקה.

הסיבה:

המוציא לאור פעיל, אבל לא שלח הודעות.

פתרון:

משתמשים במנוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות זמינה, סימן שהמוציא לאור פעיל ואין הודעות חדשות.

הפונקציה InstantReader read_latest_message()‎ מחזירה שגיאה פנימית

שגיאה:

read_latest_message() החזרות Internal שגיאה.

הסיבה:

המוציא לאור פעיל, אבל לא שלח הודעות.

פתרון:

משתמשים במנוי או בהיסטוריה עם זרם זמינות. אם ההודעה האחרונה בזרם הזמינות זמינה, סימן שהמוציא לאור פעיל ואין הודעות חדשות.

פתרון בעיות של הצפת מאגר או אובדן נתונים

שגיאות יכולות להתרחש כשהמוציא לאור שולח הודעות בקצב מהיר יותר ממה שהקורא יכול לעבד.

הקריאה הראשונה של המנוי אחרי חריגה מחזירה שגיאת DataLoss

שגיאה:

read_next_message() החזרות DataLoss שגיאה.

הסיבה:

בעל התוכן הדיגיטלי שולח הודעות בקצב מהיר יותר מזה שבו הקורא יכול לעכל אותן.

פתרון:

הקריאה הראשונה ל-next() של Observer אחרי הצפת נתונים מחזירה שגיאת DataLoss

שגיאה:

next() החזרות DataLoss שגיאה.

הסיבה:

בעל התוכן הדיגיטלי שולח הודעות בקצב מהיר יותר מזה שבו הקורא יכול לעכל אותן.

פתרון: פתרונות אפשריים:

• המוציא לאור מפרסם בקצב איטי יותר. לדוגמה, יכול להיות שיש לכם משתנה עם חותמת הזמן של ההודעה האחרונה. אם השעה הנוכחית קטנה מזמן הפרסום האחרון בתוספת דלתא, ההודעה לא מתפרסמת. באמצעות המנגנון הזה, מתפרסמת לכל היותר הודעה אחת לכל דלתא.

• הצרכן משתמש באובייקט InstantRead במקום באובייקט observer. אובייקט InstantRead לא מחזיר שגיאות של חריגה מגבולות הזיכרון, ותמיד מחזיר את ההודעה האחרונה. אם רק ההודעה האחרונה חשובה לכם, אתם יכולים להשתמש באובייקט InstantRead במקום באובייקט observer.

• הצרכן מטמיע דגימה. אם לפתרון שלכם יש רכיב publisher‏ (P1) שמפרסם הודעות מהר יותר מהרכיב observer‏ (O1) שיכול לקרוא אותן, אתם יכולים ליצור רכיב publisher חדש (P2) ורכיב observer חדש (O2) כדי להתאים את ההבדל בין מהירות הפרסום למהירות הקריאה.

  לדוגמה, נניח ש-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 קורא לשיטה והשיטה לא זמינה

שגיאה:

הפעלת method נכשלת עם השגיאה Unavailable.

הסיבה:

הפונקציה SDV לא יודעת את שם השרת ומחזירה את הערך Unavailable. השגיאה הזו מוחזרת על ידי תוכנת הביניים אם גילוי השירות לא מחזיר שם שרת תקין.

פתרון:

מתחילים חבילת שירותים שמגדירה server לממשק הנתון שבו הלקוח רוצה להשתמש.

הטמעה בצד השרת מחזירה שגיאת SdvStatus

שגיאה:

ההטמעה בצד השרת מחזירה SdvResult שמכיל SdvStatus שגיאה, כמו SdvStatusCode::NotFound. השגיאה מועברת חזרה ללקוח שביצע את הקריאה.

הסיבה:

ה-SDV ומערכת התקשורת בין הלקוח לשרת פועלים כמצופה, אבל הלקוח שלח בקשה שגורמת לשגיאה בשרת.

פתרון:

צריך לשלוח בקשה תקינה באמצעות הלקוח או לתקן את השרת כדי שיוכל להגיב לבקשות האלה.