Play Framework应用程序在Linux上崩溃 [英] Play Framework application crashes on Linux

问题描述

我有一个Play(1.2.4)应用程序，可以在Windows 7 64位开发机上正常工作.

I've got a Play (1.2.4) application that's working fine on my Windows 7 64bit dev machine.

当我在Java 7.0 beta上运行时，发生了几次崩溃；此JavaVM崩溃将出现在特定的代码修改上，但是没有任何逻辑"原因(例如，添加了crud admin类)，但是我切换到最新的7.0_2，并且现在在Windows上一切正常.

I had a few crashes when I was running on Java 7.0 beta; this JavaVM crashes would appear on specific code modifications but without any "logical" reason (eg adding a crud admin class), but I switched to latest 7.0_2 and all is fine on windows now.

但是我的部署机器是Linux.

BUT my deployment machine(s) is/are Linux.

同样，一切正常，但是在我最近的代码更新之后，它一直崩溃.

Again, all was working fine, but after my recent code update it keeps crashing.

~ play! 1.2.4, http://www.playframework.org
~
~ Ctrl+C to stop
~
Listening for transport dt_socket at address: 8000
05:20:36,845 INFO  ~ Starting /home/scrosta/PROJECT
05:20:36,849 INFO  ~ Module crud is available (/home/scrosta/play-1.2.4/modules/crud)
05:20:36,849 INFO  ~ Module jqueryui is available (/home/scrosta/PROJECTNAME/modules/jqueryui-1.0)
05:20:36,850 INFO  ~ Module logisimayml is available (/home/scrosta/PROJECTNAME/modules/logisimayml-1.5)
05:20:36,850 INFO  ~ Module secure is available (/home/scrosta/play-1.2.4/modules/secure)
05:20:36,851 INFO  ~ Module deadbolt is available (/home/scrosta/PROJECTNAME/modules/deadbolt-1.4.3)
05:20:37,461 WARN  ~ You're running Play! in DEV mode
05:20:37,522 INFO  ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...
05:21:07,468 INFO  ~ Connected to jdbc:h2:mem:play;MODE=MYSQL
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f3c3cb7a438, pid=17664, tid=139896551085824
#
# JRE version: 6.0_22-b22
# Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.10.4
# Distribution: Ubuntu 11.04, package 6b22-1.10.4-0ubuntu1~11.04.1
# Problematic frame:
# V  [libjvm.so+0x5ec438]  PhaseIdealLoop::build_loop_late_post(Node*)+0x158
#

整个日志都可以在关于馅饼的信息中

我用一台Gentoo机器进行了测试:IcedTea Java 6和Oracle Java 7，以及另一台装有IcedTea Java 6的Ubuntu计算机.同样的问题.在Windows上也没有问题.

I tested with one Gentoo machine: IcedTea Java 6 and Oracle Java 7, and a different Ubuntu machine with IcedTea Java 6. Same problem. And no issue on Windows.

我确实再次运行了依赖项，并且玩起来也很干净.

I did run dependencies again, and play clean too.

有什么想法会引起这种情况，如何解决，如何调试...?

Any idea of what could be provoking this, how to solve, how to debug...?

PS.

play precompile

运行良好.

正如我提到的，在切换到最新的Java 7.0_2之前，我曾经在Windows上遇到几乎相同的错误.

As I mentioned, I used to get pretty much the same error on windows before switching to the latest Java 7.0_2.

自从在Linux上，我从两个不同的供应商处获得了JDK 6和7以来，我认为这是不可能的.

Since on Linux I was getting it with both the JDK 6 and 7 from two different vendors, I thought it couldn't be related.

好，最后，删除我的Crud Controllers中的一个 解决了这个问题-这意味着应用程序再次运行.

WELL, ends up that removing one of my Crud Controllers solves the issue - meaning, the application runs again.

因此，我很想将责任归咎于CRUD模块(但是希望针对Linux的新Java更新将解决此问题).

I am thus tempted to blame the CRUD module (but hoping a new java update for Linux will solve the issue).

如果有人在玩！有兴趣进一步了解我的班级课程，请发表评论.

If somebody from play! is interested in knowing more about my crud classes, please comment.

编辑2

删除一些粗糙的类显然解决了这个问题，听起来可能有些零碎.

Removing some crud classes had apparently solved the issue, as patchy as it might sound.

但是我现在不得不转移到JBoss部署中，并且该错误又回来了！

But I now had to move to a JBoss deployment, and the bug is back again!

它实际上破坏了整个JBoss ，并且具有完全相同的错误...

It actually crashes the whole JBoss with exactly the same error...

推荐答案

由于Eclipse编译器，这肯定是Java的错误.

This is definitely a bug with Java due to Eclipse compiler.

play.lighthouse 上有一个可跟踪的错误.

There is a bug to track on play.lighthouse.

CRUD类似乎加剧了这个问题，并且内存不足；该问题将趋于消失，只会重新进行热编译(无需重新启动即可修改Java代码)，甚至并非总是如此.

It does seem that CRUD classes exacerbate the issue, and low memory too; the issue will tend to disappear, and only come back for hot-compilation (modifying Java code without restarting), and even there not always.

另一方面，在JBoss中进行部署肯定会导致完全崩溃.

On the other side, deploying in JBoss definitely brings to full crashes.

使用很少的Crud类和大量可用内存，情况会有所改善，因此作为一种您真的无能为力的解决方法:将CRUD类的数量减少到最少；再次使用@For装饰器似乎会使情况更糟.

With little crud classes and lot of available memory the situation improves, so as a workaround when you really can't do anything else: reduce to the minimum the number of CRUD classes; using the @For decorator again seems to worsen things.

此外，使用Java 6更加稳定-对内存的敏感性降低-尤其是在JBoss中.

Also, using Java 6 is much more stable - less memory sensitive - in particular with JBoss.

我将其标记为已解决，因为，除了CRUD技巧和使用Java 6的建议外，在此级别上别无选择.

I'll mark this as solved because, beside the CRUD trick and the suggestion to use Java 6, there's nothing else that can be done at this level.

这篇关于Play Framework应用程序在Linux上崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！