פתרון בעיות שקשורות לכשלים ב-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 לא מחזירה הודעות חדשות, אלא רק הודעות ישנות יותר.

הסיבה:

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

הפתרון:

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

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

שגיאה:

הפונקציה read_latest_message מחזירה את השגיאה Internal.

הסיבה:

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

הפתרון:

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

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

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

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

שגיאה:

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

הסיבה:

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

הפתרון:

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

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

שגיאה:

הפונקציה next מחזירה את השגיאה Internal.

הסיבה:

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

הפתרון:

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

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

שגיאה:

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

הסיבה:

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

הפתרון:

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

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

שגיאה:

הפונקציה read_latest_message מחזירה את השגיאה Internal.

הסיבה:

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

הפתרון:

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

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

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

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

שגיאה:

הפונקציה read_next_messages מחזירה את השגיאה DataLoss.

הסיבה:

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

הפתרון:

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

• מגדילים את מאגר הנתונים המעגלי של המפרסם capacity בהגדרת הארכיטקטורה של VSIDL, כדי שהתור יוכל לקלוט פרצי הודעות לפני שהמנוי קורא אותן.
• לצרוך הודעות בתדירות גבוהה יותר במנוי או להפחית את קצב ההודעות של בעל התוכן הדיגיטלי.
• אם השירות שלכם צריך רק את ערך ההודעה האחרון ולא צריך לעבד כל עדכון ביניים, השתמשו ב-InstantReader במקום ב-Subscriber.

הפעולה הבאה הראשונה של הצופה אחרי גלישה מחזירה שגיאת DataLoss

שגיאה:

הפונקציה next מחזירה את השגיאה DataLoss.

הסיבה:

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

הפתרון:

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

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

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

• הצרכן מטמיע דגימה. אם בפתרון שלכם יש בעל תוכן דיגיטלי (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 ++;
  }
  }
  

ההיסטוריה לא נטענת במלואה

שגיאה:

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

הסיבה:

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

הפתרון:

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

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

‫InstantReader מקריא רק את ההודעה האחרונה

שגיאה:

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

הסיבה:

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

הפתרון:

לא רלוונטי

לקוח RPC קורא לשיטה והשיטה לא זמינה

שגיאה:

הפעלת ה-method נכשלת ומוצגת השגיאה Unavailable.

הסיבה:

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

הפתרון:

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

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

שגיאה:

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

הסיבה:

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

הפתרון:

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