2009-03-01 7 views
6

Ich habe den Java-Service-Wrapper in einer benutzerdefinierten Anwendung für eine ganze Weile verwendet, und es hat gut funktioniert. Seit der Aktualisierung unserer Anwendung auf eine neue Version in den letzten Tagen begann die JVM zu hängen und dann Wrapper druckt dies in das Protokoll: JVM erscheint aufgehängt: Zeitüberschreitung beim Warten auf Signal von JVM.Java scheint hängen

Es beendet dann automatisch die JVM und startet die App erneut. Dies geschieht nach ungefähr 10 Stunden Laufzeit, was das Debuggen erschwert.

Natürlich werde ich die Änderungen durchsehen, die wir gemacht haben, aber es wurden keine wesentlichen Änderungen vorgenommen, von denen ich vermute, dass sie diese Art von Problemen verursachen.

Wo kann ich versuchen herauszufinden, was passiert? Debug-Nachrichten von der Anwendung zeigen nichts Interessantes an. Wenn die JVM gerade abstürzt, erstellt sie normalerweise einen Dump, der beim Debuggen helfen kann, aber sie hängt, also erstellt sie keinen Dump. Wenn ich den Dienst nicht automatisch neu starten lasse, kann ich etwas tun, um vor dem Neustart nützliche Informationen aus der JVM zu erhalten?

Es scheint mir, dass die JVM nicht von typischen Programmierfehlern hängen sollte. Worauf hast du schon einmal hingewiesen, dass die JVM hängen kann?

Antwort

1

Ich hatte ein paar verschiedene Versionen einer Bibliothek auf dem Klassenpfad (JBPM). Mit wrapper können Sie Platzhalter verwenden, um jars einzuschließen. Seien Sie vorsichtig damit, da Sie versehentlich mehr als Sie sollten einschließen.

Hier ist ein IBM Artikel, der Informationen zu debugging hangs in Java gibt. Es sagt im Grunde, dass es zwei Dinge, die Hänge verursachen können:

  1. Eine Endlosschleife,
  2. Ein Deadlock.

Seitdem musste ich andere hängenden Probleme debuggen. Unter Linux können Sie der JVM das QUIT-Signal senden, damit sie einen Thread-Dump an die Konsole sendet. Dies hilft wirklich herauszufinden, wo das Problem liegt. Verwenden Sie diesen Befehl, das zu tun: kill -quit

bearbeiten 6/13/2017

In diesen Tagen ich jmap im JDK enthalten verwenden den gesamten Speicher des Programms zu entleeren. Dann benutze ich Eclipse Memory Analyzer, um den genauen Status des Programms zu sehen, wenn es abgestürzt ist. Sie können sich die Liste der aktiven Threads ansehen und dann die Variablen in jedem Stack-Frame untersuchen.

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID> 

Wobei PID die Prozess-ID des Java-Prozesses ist.

1

In welcher Umgebung befinden Sie sich? Betriebssystem, JVM-Version, Hardware-Architektur?

Das klingt wie ein Käfer, und angesichts der Tatsache, dass es viele Stunden dauert, klingt es wie ein Ressourcen-Erschöpfungs-Bug.

+0

Linux RHEL4, Java 1.6.0, Intel 32 Bit. Ich überwache die Anzahl der Threads und die Speichernutzung. Bis jetzt benutzt es nicht viel von beiden. Wir verwenden Threads nicht viel. Wir starten nur wenige zur Startzeit der Anwendung, um alle paar Minuten nachzusehen, ob etwas zu verarbeiten ist. –

+0

Wie konsistent sind die 10 Stunden? Es gibt wirklich nur ein paar Möglichkeiten: entweder * einige * Ressourcen Erschöpfung, oder eine zufällige Deadlock/Verzögerung. Welche Art von Anwendung? –

+0

Nicht konsistent. Bis jetzt ist es nur dreimal passiert. Eigentlich sieht es so aus, als wäre der Durchschnitt ein bisschen höher als 10 Stunden. Es passierte um 12, 14 und 19 Uhr. Was ich versuchen werde, ist, es nicht auf automatischen Neustart zu setzen, damit ich den Zustand ein wenig untersuchen kann, wenn es passiert. –

8

Lesen Sie die wrapper.ping.timeout property. Die Wrapper-Software kommuniziert ab und zu mit Ihrer JVM, um sicherzustellen, dass sie aktiv ist. Wenn diese Kommunikation aus irgendeinem Grund fehlschlägt, hält der Wrapper den Prozess für blockiert und versucht, ihn neu zu starten.

Je nachdem, wie Ihre Anwendung aufgebaut ist, ist Ihre JVM möglicherweise damit beschäftigt, etwas anderes zu verarbeiten, wenn der Wrapper versucht, sie "anzupingen".

+0

Das Erhöhen der Eigenschaft kann dazu führen, dass der Wrapper das Problem nicht bemerkt und die App nicht neu startet, aber das ist nur eine Lösung für das Problem. Während der Zeit, in der es hängt, würde es nicht auf Client-Anfragen reagieren, was auch nicht gut ist. –

2

Sehen Sie, ob Sie die Visual VM verwenden können, um zu sehen, was vor sich geht. Lassen Sie die Visual VM die App für die gesamte Zeit überwachen und wenn sie nicht mehr funktioniert, können Sie möglicherweise feststellen, was falsch ist.

Wenn die VM hängt, können Sie den Status der Threads abrufen ... Ich denke, die Visual VM macht es ein wenig einfacher, wenn Sie Ihre Einrichtung als die üblichen Strg-Break (oder was auch immer die Tastenkombination ist).

(Bearbeiten basierend auf Kommentar)

dies versucht. Letztes Mal hing es die Anzahl der Threads und die Menge an Speicher im Einsatz waren ziemlich niedrig, so dass keiner von ihnen das Problem verursacht. Leider, nachdem es hängt und Wrapper beendet es können Sie nicht erhalten einen Thread-Dump.

Gibt es eine Möglichkeit, Sie können es ohne den Wrapper ausführen, um es zu debuggen? Auch wenn Sie den NetBeans-Profiler verwenden, erhalten Sie möglicherweise eine Chance, damit umzugehen, wenn er aufhört (ich werde später nachsehen und sehen, ob ich herausfinden kann, ob sich das anders verhalten würde).

+0

Versucht dies. Beim letzten Mal war die Anzahl der Threads sehr gering und die Menge des belegten Speichers war ziemlich niedrig, so dass keine davon das Problem verursacht. Leider, nachdem es hängt und der Wrapper es beendet, können Sie keinen Thread-Dump bekommen. –