我一直在开发环境中运行Glassfish 4
Windows
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
一切都很完美。
上周我部署到运行的Debian Linux服务器:
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
在Linux环境中运行时,应用程序会间歇性崩溃。它已经运行了几天而没有发生碰撞,然后在几个小时内坠毁了好几次。当它崩溃时,glassfish或jvm日志文件中没有错误消息,该过程就会消失,在一种情况下,jvm.log包含一个被截断的行。到目前为止我发现的唯一线索是syslog和userlog包含:
grep java *
syslog:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
syslog.1:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
user.log.1:Jan 8 10:19:30 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x0000000007974a90 ***
user.log.1:Jan 8 14:29:11 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00000000082431f0 ***
user.log.1:Jan 8 14:57:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007f805f87f490 ***
user.log.1:Jan 8 18:23:42 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007eff39829ca0 ***
除了最后的地址之外,所有错误看起来都相同。所有时间都对应于服务器崩溃的时间,因此这似乎是服务器消失的原因。
有问题的应用程序是一个文档存储系统,它接受多种格式的文档并将它们存储在MongoDB中。在可能的情况下,它还会将图像渲染为JPG格式。
它使用Apache PDF Box和Java Advanced Imaging来渲染JPG。它运行Spring Framework,SpringData MongoDB和Spring Security。它偶尔会使用jtds进行数据库访问,但这种情况并不常见,而且我很确定在崩溃时没有发生数据库活动。最近发生了图像重新处理,但在大多数崩溃时已经成功完成(未经过验证,但最近的崩溃已详细验证,并且已为最近保存的文档生成并保存了每个图像)。在最新文档上传50秒后发生了崩溃。
几乎我在网上发现的所有讨论都发生在C或C ++程序中,并且在那里是有意义的。我可以想到它在Java程序中发生的唯一方法是通过JNI(我没有使用,也许我正在使用的一些库做JNI但是如果是这样我不知道它)或者一个JVM错误。
有没有人有任何建议来尝试缩小导致此问题的原因?
我是否可以打开任何日志记录或诊断信息以获取更多详细信息?
目前,我唯一能想到的就是尝试在关闭某些功能的情况下运行应用程序一段时间(目前我对使用PDF Box的PDF渲染最为怀疑),看看哪个功能组合稳定哪个不是。如果可能的话,我宁愿采用更明确的方法(并且不需要等待几天才能看到测试是否有效!)。
答案 0 :(得分:1)
您可以尝试安装Oracle“官方”二进制文件,并指导如何为Ubuntu找到here。它使用update-alternatives
这是一个Debian工具,因此可以在Ubuntu中使用它来指向Oracle JRE安装。