Aktionen des Fehler-Monitors, wenn die Eigenschaft Monitor_Uri_List eingestellt ist

Wenn die Erweiterungseigenschaft Monitor_Uri_List eine einzelne URI oder eine URI-Liste angibt, werden bei einem Fehler-Monitortest die folgenden Schritte ausgeführt.

1. Der Fehler-Monitor testet die Sun Java System Application Server-Instanz in Übereinstimmung mit dem Zeitüberschreitungswert der Ressourceneigenschaft Probe_timeout.

2. Der Test stellt eine Verbindung mit dem Sun Java System Application Server-Server her und führt eine HTTP 1.1 GET-Prüfung aus, indem an alle URIs in Monitor_Uri_List HTTP-Anfragen gesendet und Antworten empfangen werden.

   Das Ergebnis der HTTP-Anfragen ist entweder ein Fehler oder eine erfolgreiche Ausführung. Wenn alle Anfragen eine Antwort vom Server mit Sun Java System Application Server erfolgreich empfangen, wird das Testsignal-Verfahren mit dem nächsten Zyklus aus Testen und Ruhen fortgesetzt.

   Hoher Netzwerkverkehr, hohe Systemlasten und fehlerhafte Konfigurationen können zum Fehlschlagen des HTTP GET-Tests führen. Eine falsche Konfiguration der Eigenschaft Monitor_Uri_List kann einen Fehler herbeiführen, wenn eine URI in Monitor_Uri_List einen falschen Port oder Hostnamen enthält. Wenn die Anwendungsserverinstanz beispielsweise den logischen Host schost-1 überwacht und die URI mit http://schost-2/servlet/monitor festgelegt wurde, versucht der Test, eine Verbindung mit schost-2 herzustellen, um /servlet/monitor anzufordern.

3. Der Test zeichnet einen Fehler im History-Protokoll auf, wenn die Antwort auf die Anforderung nicht innerhalb des Zeitüberschreitungswerts von Probe_timeout eingeht. Das Testsignal-Verfahren betrachtet dieses Szenario als Fehler seitens des Sun Java System Application Server-Datendienstes. Bei einem Testsignal-Fehler von Sun Java System Application Server kann es sich um einen Totalfehlschlag oder einen Teilfehlschlag handeln.

   Empfängt das Testsignal-Verfahren die Antwort innerhalb des Probe_timeout-Grenzwertes, wird der HTTP-Antwortcode geprüft. Lautet der Antwortcode "500 Interner Serverfehler", wird der Test als Totalfehlschlag betrachtet. Alle anderen Antwortcodes werden ignoriert.

   Es folgen Testsignal-Totalfehlschläge.

   • Bei einem fehlgeschlagenen Verbindungsversuch mit dem Server wird folgende Fehlermeldung empfangen. %s gibt den Hostnamen und %d die Port-Nummer an.

     Failed to connect to the host <%s> and port <%d>. Receiving a response code of 500 Internal Server Error HTTP GET Response Code for probe of %s is 500. Failover will be in progress

   • Die folgende Fehlermeldung wird bei einem Fehler empfangen, um die Testsignal-Zeichenkette erfolgreich an den Server zu senden. Das erste %s gibt den Hostnamen, %d die Port-Nummer und das zweite %s gibt weitere Einzelheiten zum Fehler an.

     Write to server failed: server %s port %d: %s.

4. Der Monitor sammelt so lange Teilfehlschläge, die innerhalb der Einstellung Retry_interval der Ressourceneigenschaft auftreten, bis sie einem Totalfehlschlag entsprechen.

   Es folgen Testsignal-Teilfehlschläge:

   • Die folgende Fehlermeldung wird empfangen, wenn ein Fehler bei der Verbindungstrennung auftritt, ehe die Probe_timeout-Einstellung abläuft. %d gibt die Port-Nummer und %s den Ressourcennamen an.

     Failed to disconnect from port %d of resource %s.

   • Werden nicht alle Testsignal-Schritte innerhalb der in Probe_timeout eingestellten Zeit abgeschlossen, handelt es sich um einen Teilfehlschlag.

   • Folgende Fehlermeldung wird empfangen, wenn die Daten auf dem Server aus anderen Gründen nicht gelesen werden können. Das erste %s gibt den Hostnamen, %d die Port-Nummer und das zweite %s gibt weitere Einzelheiten zum Fehler an.

     Failed to communicate with server %s port %d: %s

5. Je nach Fehler-History und der Einstellung der Testparameter führt ein Fehler entweder zu einem lokalen Neustart oder zu einem Failover des Datendiensts.