Bei einer unserer Kundeninstallationen hatten wir Tausende von Vorfällen derselben Ausnahme. Nach vielen gut protokollierten Stacktraces (9332) wird das Auftreten der Exception noch protokolliert, jedoch ohne Stacktrace. Nach dem Neustart des Java-Prozesses, das gleiche: Diesmal hatten wir 17858 Stacktraces und dann nur die Ausnahme auftreten selbst.
Es gibt eine ähnliche Frage hier , aber keine Antwort ...
Ist es eine log4j-Funktion oder ein Fehler? (Ich glaube an die erstere, weil ich wirklich mag, was diese Apache-Jungs machen)
Irgendwelche Ideen?
Mit Java 5 oder besser?
Dann siehst du:
Der Compiler in der Server-VM stellt nun korrekte Stack-Backtraces für alle "eingebauten" cold-in-Exceptions bereit. Wenn eine solche Ausnahme einige Male ausgelöst wird, kann die Methode zu Leistungszwecken neu kompiliert werden. Nach der Neukompilierung kann der Compiler eine schnellere Taktik auswählen, indem er zuvor zugeordnete Ausnahmen verwendet, die keine Stack-Trace bereitstellen. Verwenden Sie dieses neue Flag:
, um die Verwendung von vorab zugeordneten Ausnahmen vollständig zu deaktivieren-XX:-OmitStackTraceInFastThrow
Mit freundlicher Genehmigung der Java 5-Versionshinweise .
Klingt für mich wie ein Feature, zumindest wenn die Stack-Spuren wirklich identisch sind. Warum möchten Sie Ihre Logs vergrößern (und somit schwerer zu durchsuchen), ohne weitere Informationen zu erhalten? Prüft die Konfigurierbarkeit dieser Funktion ...
EDIT: Ich habe den log4j-Code durchgesehen und es gibt keine Spur davon. Dies würde stark darauf hinweisen, dass Roberts Antwort richtig ist. Schöne VM-Funktion IMO:)
Tags und Links java stack-trace log4j