播放框架[2.5.0 Java]-导致netty-event-loop线程阻塞，导致超时 [英] Play framework [2.5.0 java] - Blocked netty-event-loop threads resulting in timeout

问题描述

我们刚刚从Play框架2.4.3升级到2.5.0(java).但是，升级后，我们的测试会在几分钟后开始超时.在升级之前，它们运行了一个小时而没有错误.

We have just upgraded from Play framework 2.4.3 to 2.5.0 (java). However, after upgrading, our tests start getting timeout after a couple of minutes. Before the upgrade they ran for an hour without errors.

似乎某些线程被阻塞，系统只是停止响应.

It looks like some threads are getting blocked, and the system simply stops responding.

我正在使用Yourkit java profiler在我的计算机上本地运行较小版本的负载测试.最初，有16个netty-event-loop线程启动.大约一分钟后，我可以看到它们已开始阻止:

I am running a smaller version of the load test locally on my machine, with Yourkit java profiler. Initially, there are 16 netty-event-loop threads started. After about a minute, I can see that they have started blocking:

当它们阻塞时，我开始在负载测试中超时. 当我关闭测试时，这些线程似乎可以恢复:

When they block I start getting timeouts in the load test. When I turn off the test, these threads seem to recover:

我希望这里的人可以帮助我们确定是什么原因造成的.除了升级到Play 2.5所需的更改外，我们根本没有修改代码.

I am hoping someone here can help us determine what is causing this. We have not modified our code at all apart from the changes needed to upgrade to Play 2.5.

这是我们在application.conf中使用的akka​​线程池配置:

Here is the akka thread pool config we're using 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"
  }
}

探查器显示有关被阻止线程的以下信息:

The profiler shows the following info about the blocked threads:

谁能提供一些有关我们可能做错了什么的见解? 感谢您的帮助.

Can anyone provide some insight into what we might be doing wrong? Thanks for your help.

推荐答案

该问题似乎已为我们解决.我们在模板和控制器中使用Deadbolt-java 2.5.0-SNAPSHOT进行授权.我们在与Deadbolt相关的日志中看到了一些超时消息.

This issue seems to be resolved for us. We were using Deadbolt-java 2.5.0-SNAPSHOT for authorization in templates and controllers. We were seeing some timeout messages in our logs related to Deadbolt.

因此，我们从项目中完全删除了Deadbolt，现在负载测试的运行速度比以往任何时候都要快.

So we completely removed Deadbolt from our project, and now the load tests run faster than ever.

这篇关于播放框架[2.5.0 Java]-导致netty-event-loop线程阻塞，导致超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！