play framework [2.5.0 java] - Gesperrte netty-event-loop-Threads mit Timeout

Question

Wir haben gerade ein Upgrade von Play framework 2.4.3 auf 2.5.0 (java) durchgeführt. Nach dem Upgrade beginnen unsere Tests jedoch nach ein paar Minuten mit der Zeitüberschreitung. Vor dem Upgrade liefen sie eine Stunde ohne Fehler.

Es sieht aus wie einige Threads blockiert werden, und das System reagiert einfach nicht mehr.

Ich leite lokal eine kleinere Version des Auslastungstests auf meinem Computer mit Yourkit Java Profiler. Zunächst werden 16 netty-event-loop Threads gestartet. Nach etwa einer Minute, kann ich sehen, dass sie blockiert haben begonnen:

Wenn sie blockieren beginne ich Timeouts im Belastungstest bekommen. Wenn ich aus dem Test drehen, scheinen diese Fäden zu erholen:

Ich kann hier bin der Hoffnung, jemand uns helfen, festzustellen, was ist der Grund dafür. Wir haben unseren Code nicht geändert, abgesehen von den Änderungen, die für das Upgrade auf Play 2.5 erforderlich waren. Hier

ist der akka Thread-Pool Config verwenden wir in application.conf:

akka { 
    fork-join-executor { 
    # The parallelism factor is used to determine thread pool size using the 
    # following formula: ceil(available processors * factor). Resulting size 
    # is then bounded by the parallelism-min and parallelism-max values. 
    parallelism-factor = 3.0 

    # Min number of threads to cap factor-based parallelism number to 
    parallelism-min = 8 

    # Max number of threads to cap factor-based parallelism number to 
    parallelism-max = 64 

    # Setting to "FIFO" to use queue like peeking mode which "poll" or "LIFO" to use stack 
    # like peeking mode which "pop". 
    task-peeking-mode = "FIFO" 
    } 
} 

Der Profiler zeigt die folgenden Informationen über die blockierten Threads:

Kann jemand etwas Einblick in was wir falsch machen könnten? Danke für Ihre Hilfe.

Answer 1

Dieses Problem scheint für uns gelöst zu sein. Wir haben Deadbolt-Java 2.5.0-SNAPSHOT zur Autorisierung in Templates und Controllern verwendet. Wir haben in unseren Logs zu Deadbolt einige Timeout-Meldungen erhalten.

Also haben wir Deadbolt komplett aus unserem Projekt entfernt, und jetzt laufen die Belastungstests schneller als je zuvor.