Fehler bei der Middleware-API beheben

Die meisten Middleware-APIs geben ein SdvResult-Objekt zurück. Bei Erfolg enthält dieses Objekt das erwartete Ergebnisobjekt. Bei einem Fehler enthält dieses Objekt ein SdvStatus-Objekt, das auf ein unerwartetes Verhalten oder einen Fehlerzustand hinweist, der häufig durch einen Fehlercode wie Internal, Unavailable oder DataLoss identifiziert wird.

Auf dieser Seite finden Sie Informationen zur Fehlerbehebung bei diesen Fehlercodes.

Fehlerbehebung bei Registrierungs- und Erstellungsfehlern

Registrierungs- und Erstellungsfehler treten in der Regel auf, wenn Sie versuchen, einen ungültigen Dienst zu erstellen oder zu registrieren.

Zweiter Dienst kann nicht erstellt werden

Fehler:

Internal-Fehler.

Ursache:

Sie versuchen, dieselbe Servicebündelinstanz (Name und Instanz-ID) zweimal zu registrieren.

Behebung:

Versuchen Sie nicht, dieselbe Servicepaketinstanz (Name und Instanz-ID) zweimal zu registrieren.

Doppeltes Dienstpaket kann nicht gelöscht werden

Fehler:

Status(-3, EX_ILLEGAL_ARGUMENT)

Ursache:

Sie versuchen, ein doppeltes Dienstpaket zu löschen, das nicht vorhanden ist.

Behebung:

Versuchen Sie nicht, ein doppeltes Dienstpaket zu löschen, das nicht vorhanden ist.

Publisher-Instanz zum Senden von Nachrichten kann nicht abgerufen werden

Fehler:

Der Aufruf von take_publisher() gibt none zurück.

Ursache:

Sie haben take_publisher() zweimal für dieselbe Variante aus derselben Servicepaketinstanz aufgerufen.

Behebung:

Rufen Sie take_publisher() nicht zweimal für dieselbe Variante aus derselben Servicepaket-Instanz auf.

Subscriber, Observer, History oder InstantReader können nicht erstellt werden

Fehler:

Unavailable-Fehler.

Ursache:

Sie haben versucht, ein Subscriber, Observer, History oder InstantReader für einen Publisher zu erstellen, der nicht vorhanden oder abgemeldet ist.

Behebung:

Prüfen Sie, ob der Publisher vorhanden oder registriert ist, bevor Sie versuchen, eine Subscriber, Observer, History oder InstantReader für den Publisher zu erstellen.

RPC-Client kann nicht erstellt werden

Fehler:

Unavailable Fehler

Ursache:

Sie haben versucht, einen RPC-Client für einen Server-Unit-Namen zu erstellen, der nicht vorhanden oder nicht registriert ist.

Behebung:

Prüfen Sie, ob der Server vorhanden und registriert ist, bevor Sie den RPC-Client erstellen.

Kommunikationsfehler beheben

Kommunikationsfehler können auftreten, nachdem ein Dienst ausgeführt wurde und mit der Kommunikation mit anderen Diensten beginnt.

Fehlerbehebung bei der Deregistrierung von Publishern

Fehler können auftreten, wenn sich ein Verlag oder Webpublisher abmeldet, während seine Leser noch aktiv sind.

read_next_messages() des Abonnenten gibt leere Listen zurück

Fehler:

read_next_messages() wird erfolgreich ausgeführt, gibt aber leere Listen zurück.

Ursache:

Der Verlag wird abgemeldet, während seine Leser aktiv sind.

Behebung:

Verwenden Sie einen Abonnenten oder Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams nicht verfügbar ist, wird der Verlag oder Webpublisher abgemeldet und es gibt keine neuen Nachrichten.

„next()“ des Beobachters gibt internen Fehler zurück

Fehler:

next() gibt den Fehler Internal zurück.

Ursache:

Der Verlag wird abgemeldet, während seine Leser aktiv sind.

Behebung:

Verwenden Sie ein Abo oder einen Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams nicht verfügbar ist, ist der Publisher nicht mehr vorhanden und es gibt keine neuen Nachrichten.

„read_from_history()“ gibt keine neuen Nachrichten zurück

Fehler:

read_from_history() gibt keine neuen Nachrichten zurück, sondern nur ältere.

Ursache:

Der Verlag wird abgemeldet, während seine Leser aktiv sind.

Behebung:

Verwenden Sie ein Abo oder einen Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams nicht verfügbar ist, ist der Publisher nicht mehr vorhanden und es gibt keine neuen Nachrichten.

InstantReader.read_latest_message() gibt internen Fehler zurück

Fehler:

read_latest_message() gibt den Fehler Internal zurück.

Ursache:

Der Verlag wird abgemeldet, während seine Leser aktiv sind.

Behebung:

Verwenden Sie ein Abo oder einen Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams nicht verfügbar ist, ist der Publisher nicht mehr vorhanden und es gibt keine neuen Nachrichten.

Fehlerbehebung bei leerer Nachrichtenwarteschlange

Fehler können auftreten, wenn versucht wird, aus einer leeren Nachrichtenwarteschlange zu lesen.

read_next_messages() des Abonnenten gibt eine leere Liste zurück

Fehler:

read_next_messages() gibt eine leere Liste zurück.

Ursache:

Der Publisher ist aktiv, hat aber keine Nachrichten gesendet.

Behebung:

Verwenden Sie einen Abonnenten oder Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams verfügbar ist, ist der Verlag oder Webpublisher aktiv und es gibt keine neuen Nachrichten.

„next()“ des Beobachters gibt internen Fehler zurück

Fehler:

next() gibt den Fehler Internal zurück.

Ursache:

Der Publisher ist aktiv, hat aber keine Nachrichten gesendet.

Behebung:

Verwenden Sie einen Abonnenten oder Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams verfügbar ist, ist der Verlag oder Webpublisher aktiv und es gibt keine neuen Nachrichten.

„read_from_history()“ gibt keine neuen Nachrichten zurück

Fehler:

read_from_history() gibt eine leere Liste zurück.

Ursache:

Der Publisher ist aktiv, hat aber keine Nachrichten gesendet.

Behebung:

Verwenden Sie einen Abonnenten oder Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams verfügbar ist, ist der Verlag oder Webpublisher aktiv und es gibt keine neuen Nachrichten.

InstantReader.read_latest_message() gibt internen Fehler zurück

Fehler:

read_latest_message() gibt den Fehler Internal zurück.

Ursache:

Der Publisher ist aktiv, hat aber keine Nachrichten gesendet.

Behebung:

Verwenden Sie einen Abonnenten oder Verlauf mit einem Verfügbarkeitsstream. Wenn die letzte Nachricht des Verfügbarkeitsstreams verfügbar ist, ist der Verlag oder Webpublisher aktiv und es gibt keine neuen Nachrichten.

Pufferüberlauf oder Datenverlust beheben

Fehler können auftreten, wenn der Publisher Nachrichten schneller sendet, als ein Leser sie verarbeiten kann.

Erster Lesevorgang eines Abonnenten nach einem Überlauf gibt den Fehler „DataLoss“ zurück

Fehler:

read_next_message() gibt den Fehler DataLoss zurück.

Ursache:

Der Publisher sendet Nachrichten schneller, als ein Leser sie lesen kann.

Behebung:

Der erste next()-Aufruf des Observer nach einem Überlauf gibt den Fehler „DataLoss“ zurück.

Fehler:

next() gibt den Fehler DataLoss zurück.

Ursache:

Der Publisher sendet Nachrichten schneller, als ein Leser sie lesen kann.

Lösung:Mögliche Lösungen sind:

• Der Publisher veröffentlicht langsamer. Sie haben beispielsweise eine Variable mit dem Zeitstempel der letzten Nachricht. Wenn die aktuelle Zeit weniger als die letzte Veröffentlichungszeit plus ein Delta ist, veröffentlichen Sie die Nachricht nicht. Mit diesem Mechanismus wird höchstens eine Nachricht pro Delta veröffentlicht.

• Der Consumer verwendet ein InstantRead-Objekt anstelle eines Observers. Ein InstantRead-Objekt gibt keine Überlauffehler zurück und gibt immer die letzte Nachricht zurück. Wenn die letzte Nachricht die einzige ist, die für Sie wichtig ist, können Sie anstelle eines Observers ein InstantRead-Objekt verwenden.

• Der Verbraucher implementiert das Sampling. Wenn Ihre Lösung einen Publisher (P1) hat, der Nachrichten schneller veröffentlicht, als der Observer (01) sie lesen kann, können Sie einen neuen Publisher (P2) und Observer (02) erstellen, um den Unterschied in der Veröffentlichungs- und Lesegeschwindigkeit auszugleichen.

  Angenommen, P1 veröffentlicht alle 10 ms eine Nachricht, aber O1 kann nur alle 100 ms eine Nachricht lesen und verwirft die restlichen neun Nachrichten. So beheben Sie die Abweichung:

  1. P1 veröffentlicht Nachrichten für O2.
  2. O2 liest eine Nachricht und verwirft neun.
  3. O2 sendet die eine gelesene Nachricht an P2.
  4. P2 sendet die gelesene Nachricht an O1.
  5. O1 liest alle zehn Sekunden eine Nachricht.

  Das folgende Beispiel zeigt, wie Sie dieses Sampling-Szenario implementieren:

  int discarded_message = 10;
  
  while (true) {
  message m = O2.read_message();
  if discarded_message == 10 {
    discarded_message = 0;
    P2.publish(m);
  } else {
   discarded_message ++;
  }
  }
  

Verlauf wird unvollständig angezeigt

Fehler:

Die Nachricht geht vor dem Kopieren des Verlaufs verloren. Beim Lesen erfolgt keine direkte Fehlerbenachrichtigung.

Ursache:

Der Publisher sendet Nachrichten schneller, als ein Leser sie lesen kann.

Behebung:

InstantReader liest nur die letzte Nachricht vor

Fehler:

Die Nachricht geht vor dem Kopieren des Verlaufs verloren. Beim Lesen erfolgt keine direkte Fehlerbenachrichtigung.

Ursache:

Der Publisher sendet Nachrichten schneller, als ein Leser sie lesen kann.

Behebung:

–

RPC-Client ruft eine Methode auf, die nicht verfügbar ist

Fehler:

Der Methodenaufruf schlägt mit dem Fehler Unavailable fehl.

Ursache:

SDV kennt den Servernamen nicht und gibt Unavailable zurück. Dieser Fehler wird von der Middleware zurückgegeben, wenn Service Discovery keinen gültigen Servernamen zurückgibt.

Behebung:

Starten Sie ein Dienstbündel, das ein server für die angegebene Schnittstelle definiert, die der Client verwenden möchte.

Bei der serverseitigen Implementierung wird der Fehler „SdvStatus“ zurückgegeben

Fehler:

Die serverseitige Implementierung gibt ein SdvResult-Objekt mit einem SdvStatus-Fehler zurück, z. B. SdvStatusCode::NotFound. Der Fehler wird an den aufrufenden Client zurückgegeben.

Ursache:

SDV und das Kommunikationssystem zwischen Client und Server funktionieren wie erwartet, aber der Client hat eine Anfrage gesendet, die einen Fehler auf dem Server auslöst.

Behebung:

Stellen Sie eine gültige Anfrage mit dem Client oder beheben Sie den Fehler auf dem Server, damit er auf diese Anfragen reagieren kann.