Threads werden in Weblogic-Clusterumgebung blockiert

Ich habe eine Weblogic-Clusterumgebung mit 2 Instanzen von Servern. Einer davon wird gehängt und der andere funktioniert vollkommen einwandfrei. Nach dem Analysieren der Thread-Dumps kann ich sehen, dass fast 90% der Threads BLOCKED sind und nach der Verfolgung der Threads kommt es unter Stack-Trace.Threads werden in Weblogic-Clusterumgebung blockiert

"[ACTIVE] ExecuteThread: '330' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x00007f9494376000 nid=0x66a2 runnable [0x00007f944bb78000] 
    java.lang.Thread.State: RUNNABLE 
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) 
    at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) 
    at java.io.File.exists(File.java:813) 
    at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1080) 
    at sun.misc.URLClassPath.getResource(URLClassPath.java:199) 
    at java.net.URLClassLoader$1.run(URLClassLoader.java:358) 
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)

Hier finden Sie den Thread Dump für den BLOCKED Thread.

"[ACTIVE] ExecuteThread: '298' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x00007f9494352000 nid=0x6276 waiting for monitor entry [0x00007f944e09e000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.lang.ClassLoader.loadClass(ClassLoader.java:405) 
    - waiting to lock <0x0000000719e7ded8> (a weblogic.utils.classloaders.GenericClassLoader) 
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 
    at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.loadClass(PackagingDataCalculator.java:207) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.bestEffortLoadClass(PackagingDataCalculator.java:232) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.computeBySTEP(PackagingDataCalculator.java:138) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.populateUncommonFrames(PackagingDataCalculator.java:113) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:105) 
    at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:57) 
    at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:147) 
    at ch.qos.logback.classic.spi.LoggingEvent. (LoggingEvent.java:124) 
    at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) 
    at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:396) 
    at ch.qos.logback.classic.Logger.warn(Logger.java:713)

Dieser Stack-Trace ist ähnlich für alle anderen BLOCKED und Threads.

Bitte lassen Sie mich wissen, wenn jemand auf ein solches Problem gestoßen ist. Jede Hilfe wird sehr geschätzt.

Quelle

2016-08-30 RahulO

Dies ist ein Dump eines Threads im Zustand 'RUNNABLE'. Dieser Thread ist nicht blockiert, er läuft und macht etwas Arbeit (es prüft gerade eine Java-Bibliotheksexistenz, um genau zu sein). Sie müssen einen BLOCKED-Thread finden und einen Dump erstellen, damit Sie besser mit der Analyse Ihres Problems beginnen können. –

Ja. Dies ist ein RUNNABLE-Thread, aber alle BLOCKED-Threads verfolgen diesen RUNNABLE-Thread, wie ich in der Beschreibung erwähnt habe. Alle BLOCKED-Threads warten darauf, auf dem Monitor dieses Threads gesperrt zu werden. – RahulO

Das ist seltsam. Normalerweise, wenn ein Thread eine Sperre enthält, können Sie es in seinem Thread-Dump sehen (es hat eine "gesperrt" -Zeile). Es kann vorkommen, dass alle Ihre Threads die gleiche Java-Klasse laden müssen, aber der Klassenlader ist beim Laden der Bibliothek in diesen Thread hängen geblieben. Können Sie einen Thread-Dump von einem der blockierten Threads veröffentlichen? Wenn Sie Dumps dieses laufenden Threads mit einem 10-Sekunden-Intervall erstellen, haben alle diese Dumps die gleiche Stack-Ablaufverfolgung? –

Die Thread-Dumps zeigen an, dass Ihre Threads blockiert sind, während Sie versuchen, Protokollnachrichten zu schreiben. Logback benötigt eine Klasse und fordert einen Klassenlader auf, sie zu laden. Irgendwo in der Hierarchie der Klassenladeprogramme hängt einer der Klassenlader beim Laden einer Bibliothek fest, und alle anderen Threads warten, bis sie auf diesen Lader warten.

Höchstwahrscheinlich haben Sie eine Abhängigkeitsbibliothek, die auf einer bereitgestellten Netzwerkfestplatte liegt, die entweder nicht erreichbar oder extrem langsam ist oder einige fehlerhafte Blöcke aufweist. Es verursacht das hängen beim Lesen dieser Bibliothek. Überprüfen Sie Ihren Klassenpfad, überprüfen Sie die Festplatten und das Netzwerk.

Quelle

2016-08-31 08:16:41

Threads werden in Weblogic-Clusterumgebung blockiert

Antwort

Verwandte Themen