Einführung

Hängt Java auf der Serverseite vage ohne Antwort auf den Zugriff vom Browser? Kann gefragt werden. Warum sind Sie Java VM gegenüber misstrauisch? Ich möchte </ FONT> sagen, aber es scheint, dass der Grund darin besteht, dass ich mit der Untersuchung in der folgenden Reihenfolge fortfahren möchte.

Erfordert die Meinung des Support-Personals als Java VM oder Middleware, die darauf ausgeführt wird
Wenn es kein Problem gibt, ist die Antwort auf diesen Effekt OK
Mit der Meinung des Support-Personals möchte ich mich bei Bedarf an das Netzwerk- oder Datenbankpersonal wenden.

Ich werde ein allgemeines Beispiel für diese Situation veröffentlichen.

Java-Thread-Dump

Wenn Sie den Java-Thread-Dump erhalten, funktioniert die Java-VM-Funktion ordnungsgemäß. Man kann also sagen, dass sich die Java-VM selbst nicht in einer blockierten Situation befindet. Schauen wir uns jedoch zuerst den Inhalt an.

** Thread Dump des Problemteils **

"default task-4" #116 prio=5 os_prio=0 tid=0x0000000003ba3800 nid=0x7894 runnable [0x00007f58c80c7000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at oracle.net.ns.Packet.receive(Packet.java:311)
        at oracle.net.ns.DataPacket.receive(DataPacket.java:105)
        at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:305)
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:249)
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:171)
        at oracle.net.ns.NetInputStream.read(NetInputStream.java:89)
        at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:123)
        at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:79)
        at oracle.jdbc.driver.T4CMAREngineStream.unmarshalUB1(T4CMAREngineStream.java:426)
        at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:390)
        at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)
        at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)
        at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:202)
        at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:45)
        at oracle.jdbc.driver.T4CStatement.executeForDescribe(T4CStatement.java:766)
        at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)
        at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1026)
        at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:1244)
        - locked <0x00000000fcd35220> (a oracle.jdbc.driver.T4CConnection)
        at oracle.jdbc.driver.OracleStatementWrapper.executeQuery(OracleStatementWrapper.java:420)
        at org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:397)
        at abc.doGet(abc.java:37)
...Unterlassung...

Wenn Sie in diesem Beispiel auf ein Servlet namens abc zugreifen, erhalten Sie keine Antwort. Wenn Sie sich jedoch den Stapel ansehen, der sich auf dieses abc bezieht, sieht es wie oben aus. Von unten nach oben können Sie von doExecuteWithTimeout in jdbc bis NetInputStream.read und socketRead0 sehen und auf einen Lesevorgang warten. Das Warten von einigen zehn Sekunden und das erneute Abrufen eines Thread-Dumps ändert nichts an dieser Situation. Es scheint, dass das jdbc-Timeout erreicht wurde, weil es irgendwie doExecuteWithTimeout gibt. Mit anderen Worten, die folgende fünfte Operation fährt während des Wartens nicht mit dem nächsten Vorgang fort.

HTTP-GET-Anforderung vom Browser zum Server
Das Servlet wirft SQL mit jdbc an oracle, um den Antwortinhalt zu erstellen.
Die SQL-Antwort wurde nicht innerhalb des Abfragezeitlimits erhalten.
Geben Sie jdbc einen Abbruch mit Anweisung.Cancel als Timeout-Prozess aus
Warten auf die Antwort auf die Stornierung.
Wenn Sie eine Antwort auf die Stornierung erhalten, wird diese als SQLTimeoutException behandelt und die Ausnahme wird behandelt ... Möglicherweise.

** Hinweis: Anweisung.Cancel wird abgebrochen, indem es an eine Datenbank ausgegeben wird, die korrekt reagiert. **

Gab es also ein Problem mit der Datenbank? ?? ?? Das könnte man denken.

Die Ansicht von der Datenbankseite

Fragen Sie anhand des Inhalts des Thread-Dumps, ob während dieses Zeitraums auf der Datenbankseite ein Fehler aufgetreten ist ... ** Es wurden keine Anomalien gefunden. ** Was vermuten Sie überhaupt an DB? Mir wurde gesagt, </ FONT>.

Wird das Stornierungspaket gesendet?

Wenn es kein Problem mit der Datenbank gibt, frage ich mich, ob statement.cancel wirklich ausgeführt und als Paket an die Datenbank gesendet wird. Lassen Sie uns das Problem reproduzieren und das Paket zur Bestätigung erfassen.

** Auf der Systemseite läuft Java **

statement.Paket entsprechend abzubrechen

13:14:08.948939 IP rhel74.38860 > 192.168.1.25.1521: Flags [P.U], seq 4510:4511, ack 5404, win 44020, urg 1, length 1
..s....
        0x0010:  c0a8 0119 97cc 05f1 f070 d6a2 c3a2 111d  ......-..p......
        0x0020:  5038 abf4 cdeb 0001 21                   P8......!

Beachten Sie die Flags [P.U], für die die Flags P.U oder PUSH und URG gesetzt sind. Und die Benutzerdaten sind ein Zeichen von "!". An diesem Inhalt können Sie erkennen, dass Anweisung.Cancel ausgeführt wird und die Stornierungsanforderung korrekt gesendet wird.

** Auf der Empfangsseite? ** ** ** Wenn ich eine Paketerfassung nehme und sie auf dem System auf der Datenbankseite überprüfe, kann das oben genannte Paket nicht gefunden werden. Es ist so, dass irgendwo verworfen wurde, weil es die Vielzahl von Netzwerkgeräten Yara NAT durchlaufen hat.

Nach meiner Erfahrung habe ich ein Muster gesehen, bei dem nur das URG-Flag von TCP gelöscht wurde. Die Oracle-Datenbankseite antwortet nicht auf "!" - Pakete, für die kein URG festgelegt ist.

Auf diese Weise ist es nicht möglich, das zeitaufwändige SQL abzubrechen und abzubrechen, wenn die Abbruch der Anweisung in der Datenbank nicht wie erwartet erreicht wird, was zu einer endlosen Antwort führt. Ich werde.

Das Problem liegt im Netzwerk

Ich vermute, dass ein Mechanismus wie NAT oder Firewall im Netzwerkpfad dieses mit URG gekennzeichnete Paket nicht korrekt verarbeitet. Aufgrund der erfassten Paketerfassung denke ich daher, dass die für das Netzwerk verantwortliche Person gefragt wird, ob das Paket mit diesem URG-Flag nicht angekommen ist. Auch Was vermuten Sie am Netzwerk? Sie könnten </ FONT> genannt werden, aber ...

Es gibt eine Vielzahl von Fehlern, wenn ein Problem auftritt.

Im Falle eines solchen Musters des Wartens auf eine Antwort von jdbc und der Stornierung ist es nicht immer effektiv, dass es nicht immer nur einen Ereignistyp gibt. Nach dem Starten einer Transaktion kann beispielsweise JTA (Java Transaction API) so eingestellt werden, dass eine unvollständige Transaktion wiederhergestellt wird. Wenn der Wiederherstellungsvorgang so eingestellt ist, dass alle 30 Minuten versucht wird, bis 24 Stunden vergangen sind, wird auf dieselbe Abbruchantwort gewartet, auch wenn der Wiederherstellungsvorgang versucht wird. Alle 30 Minuten erhöht sich die Anzahl der Wiederherstellungsthreads, und infolgedessen werden schließlich viele Threads erstellt. Zu viele Fehler bei geöffneten Dateien und Ressourcenfehler, z. B. Neuer nativer Thread kann nicht erstellt werden. Es kann dazu führen. Da es erst nach Ablauf von 24 Stunden aufgibt, wird derselbe Vorgang auch dann wiederholt, wenn er neu gestartet wird.

Aufgrund dieser Punkte halte ich es für wichtig, den Zeitablauf und den Inhalt des Thread-Dumps zu überprüfen, um zu verstehen, was passiert.

Wir hoffen, dass Sie dies nützlich finden.