Das OpenVOS-Betriebssystem bietet eine hochrangige Anwendungsprogrammierschnittstelle (API), die die Programmierung des Systems im Großen und Ganzen einfach macht. Aber manchmal wird es zu einfach - weil ein einfacher Unterprogrammaufruf zu einer s$... Routine eine Menge Komplexität verbergen kann. Die Benutzer sind sich manchmal nicht bewusst, dass der einfache Aufruf zu einer Menge Arbeit führen kann und Probleme für das System und die Anwendung verursachen kann.
Dies ist der zweite Teil einer unregelmäßigen Serie von Beiträgen, die Sie auf Fallstricke aufmerksam machen sollen, die Sie bei der Gestaltung Ihrer Anwendungen vermeiden können.
Die Übel von list_messages für Server-Warteschlangen
Der Befehl list_messages in OpenVOS ist für die Verwendung mit Warteschlangen vorgesehen, die Teil des Transaktionsschutzprodukts für OpenVOS sind. StrataDOC für OpenVOS zeigt, dass dieser Befehl "Informationen über die Nachrichten in einer bestimmten Warteschlange anzeigt". Wenn also Warteschlangen in der Produktion anfangen, sich zu stauen, könnten Sie versucht sein, diesen Befehl zu benutzen, um herauszufinden, wie viele Nachrichten sich in der Warteschlange befinden. Die Option -totals_only sieht genau so aus, wie sie gebraucht wird. Sobald Sie verstehen, wie dieser Befehl funktioniert, werden Sie verstehen, warum dies keine gute Wahl ist.
Funktionsweise des Befehls list_messages
Der Befehl hängt einen Port an die Datei an und öffnet den Port als SERVER_TYPE (oder RECV_ONLY_SRV_TYPE für eine einseitige Serverwarteschlange) und versetzt ihn in den no_wait_mode. Wenn die Warteschlange transaktionsgeschützt ist, dann startet der Befehl eine Transaktion mit der Priorität -1, was bedeutet, dass er immer verlieren wird, wenn es einen Konflikt gibt, und wenn er fertig ist, ruft er s$abort_transaction auf.
Als Nächstes beginnt es mit dem ersten Datensatz in der Warteschlange und ruft s$read_msg auf, um jeden Datensatz zu zählen, den es empfangen kann, und zählt dann den Datensatz und/oder gibt ihn an den Ausgabeport aus.
Um Informationen über jede Nachricht anzuzeigen, muss es Informationen über das Modul und den Prozess, von dem die Nachricht stammt, nachschlagen.
Schließlich werden die Summen der in der Warteschlange gefundenen Datensätze ausgedruckt.
Probleme mit diesem Ansatz
Der Befehl war für Anwendungsentwicklungsprogrammierer gedacht, um Nachrichten in der Warteschlange zu prüfen, um festzustellen, ob die Nachricht richtig formatiert war und die richtigen Felder enthielt, ob sie mit der richtigen Priorität in die Warteschlange gestellt wurde, ob sie von einem Server empfangen wurde oder nicht usw. Allerdings gibt es viele Einschränkungen und versteckte/irreführende Daten, wenn der Befehl für andere Zwecke verwendet wird:
- Um Informationen über Nachrichten in einer Warteschlange zu erhalten, müssen Sie Ausführungs-, Lese- oder Schreibzugriff auf die Warteschlange haben. Wenn Sie Ausführungs- oder Lesezugriff auf die Warteschlange haben, können Sie nur Informationen über Ihre Nachrichten abrufen. Wenn Sie Schreibzugriff haben, können Sie Informationen über alle Nachrichten abrufen.
- Handelt es sich bei der Warteschlange um eine Server-Warteschlange, listet list_messages nur die Nachrichten auf, die noch nicht vom Server beantwortet worden sind. Nachrichten, auf die geantwortet wurde, die aber noch nicht durch s$msg_receive_reply aus der Warteschlange entfernt wurden, werden nicht aufgelistet.
- Die Warteschlange könnte voll sein (max_queue_depth) und keine neuen Nachrichten mehr annehmen, aber list_messages könnte null Nachrichten in der Warteschlange anzeigen, wenn alle Nachrichten nicht empfangene Antworten sind.
- Da der Befehl list_messages als Server der Warteschlange erscheint, während er Nachrichten abruft, könnte er Clients und andere Kontrollprozesse über die Anzahl der Server täuschen, die die Warteschlange bedienen.
- Das Abrufen von Modul- und Prozessinformationen über die Anforderungsprozesse kann Netzwerktransaktionen erfordern, wenn sich die Anforderer in einem anderen Modul befinden.
- Jede Nachricht erfordert einen Eingriff in den Kernel, um die Nachricht zu lesen. Wenn der Befehl nicht von dem Modul ausgeführt wird, dem die Warteschlange gehört, ist eine Netzwerktransaktion erforderlich, um jede Nachricht zu lesen.
- Auch wenn -totals_only angegeben ist, muss jede Nachricht gelesen werden, um gezählt zu werden.
- Der von -totals_only angezeigte Wert bezieht sich NUR auf Nachrichten, die sich entweder in einer Warteschlange für einen Server befinden oder von einem Server verarbeitet werden. Es werden keine Informationen über nicht empfangene Antworten auf Nachrichten in Zwei-Wege-Server-Warteschlangen angezeigt, die sich noch in der Warteschlange befinden, so dass -totals_only-Werte irreführend sind.
- Bei den Daten in den Nachrichten kann es sich um sensible Informationen handeln (z. B. Kreditkartenkontonummern).
Eine andere Methode
Im Jahr 1990 wurde eine neue API bereitgestellt: s$get_server_queue_info. Mit dem Pfadnamen einer Warteschlange gibt diese Routine eine Struktur mit
- Die Art der server_queue (einseitig oder zweiseitig)
- Die Anzahl der Nachrichten
- Die Anzahl der nicht belegten Nachrichten
- Die höchste Anzahl von Nachrichten
- Die Gesamtzahl der verarbeiteten Nachrichten.
- Die konfigurierte maximale Anzahl von Nachrichten (max_queue_depth) für diese Warteschlange.
Diese Routine hat viele Vorteile gegenüber list_messages:
- Eine Reise in den Kernel und/oder über das Netzwerk zum Abrufen von Summeninformationen.
- Berücksichtigung aller Arten von Nachrichten, einschließlich noch nicht erhaltener Antworten.
- Keine Unterbrechung der Warteschlange. Der Warteschlangenkopf wird für Mikrosekunden gesperrt, gerade lange genug, um einen konsistenten Satz von fünf Zählern aus dem Warteschlangenkopf zu erhalten.
- Die Informationen können abgerufen werden, wenn die Warteschlange als Antragsteller geöffnet wird.
check_queue_depth Befehl
Vor vielen Jahren habe ich check_queue_depth geschrieben, einen Befehl, der diese Schnittstelle nutzt und mit dem Sie nicht nur diese Informationen für eine oder mehrere Warteschlangen anzeigen können, sondern der auch die Überwachung und Warnung bei Erreichen von Schwellenwerten ermöglicht.
check_queue_depth queues [-warn_percent number] [-interval number]
[-notify user_name] [-brief] [-long]
[-ignore_invalid_type] [-syserr]
[-exit_after_warning]
Der Quellcode für den Befehl ist auf der öffentlichen FTP-Site Stratus verfügbar.
- Dokumentation http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- Quellcode http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
Sie können es gerne verwenden, erweitern und/oder in Ihre eigenen Anwendungsüberwachungsbefehle einbetten.