小编vkr*_*ser的帖子

我们正在研究客户端的生产服务器堆,以检测和解决内存泄漏问题.为此,我们定期使用jmap来收集必要的信息.

但是上周我们无法进行转储,因为它触发了EOF错误并关闭了Tomcat实例.

我在互联网上搜索,但找不到有关此错误的任何具体信息.我们检测到只有在使用Gc First垃圾收集器算法时才会发生.

这是我们用来执行jmap的命令行:

jmap -dump:format=b,file=heap.bin <PID>

服务器上的Java版本:JDK 1.7.0_7 x64

有没有人遇到过这种错误？可能缺少一些配置或需要java/jmap的补丁.

UPDATE

我们收集的有关此错误的更多信息:

[root]# jmap -dump:format=b,file=heap.bin 7806
    Dumping heap to /tmp/heap.bin ...
    Exception in thread "main" java.io.IOException: Premature EOF
        at sun.tools.attach.HotSpotVirtualMachine.readInt(HotSpotVirtualMachine.java:244)
        at sun.tools.attach.LinuxVirtualMachine.execute(LinuxVirtualMachine.java:193)
        at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213)
        at sun.tools.attach.HotSpotVirtualMachine.dumpHeap(HotSpotVirtualMachine.java:180)
        at sun.tools.jmap.JMap.dump(JMap.java:241)
        at sun.tools.jmap.JMap.main(JMap.java:140)
[root]#

注意:目标目录有超过500GB的可用空间

错误输出到catalina.out(JVM转储错误):

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f0269cc41c6, pid=7806, tid=139647231129360
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# …

我们目前正在运行WebLogic 12.1.2.在这种环境下我们的应用运行良好.

我们现在想要的是将我们的应用程序同步到WebLogic 12.1.3环境.但我们正面临着我们使用的Web服务的问题.在新版本中,服务器抛出一个异常,说"找不到默认配置文件[metro-default.xml]".

我试图在这个文件上找到一些东西,但什么都没有.

PS:我们不使用Metro,我们使用WebLogic默认的JAX-WS堆栈.该应用程序部署为WAR文件.

这是异常的堆栈

java.lang.IllegalStateException: MASM0001: Default configuration file [ metro-default.xml ] was not found
    at com.sun.xml.ws.assembler.MetroConfigLoader.init(MetroConfigLoader.java:142)
    at com.sun.xml.ws.assembler.MetroConfigLoader.<init>(MetroConfigLoader.java:119)
    at com.sun.xml.ws.assembler.TubelineAssemblyController.getTubeCreators(TubelineAssemblyController.java:122)
    at com.sun.xml.ws.assembler.MetroTubelineAssembler.createServer(MetroTubelineAssembler.java:173)
    at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:193)
    at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:337)
    at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:332)
    at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:164)
    at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:577)
    at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:560)
    at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:303)
    at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:179)
    at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:131)
    at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:152)
    at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:678)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
    at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
    at weblogic.servlet.internal.EventsManager.executeContextListener(EventsManager.java:243)
    at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:200)
    at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:185)
    at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1838)
    at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2876)
    at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1661)
    at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:823)
    at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360)
    at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
    at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138)
    at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
    at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) …

我们正在寻求针对我们软件的新架构方法的建议.

目前,我们正在为ERP开发新的前端,我们开始时选择的框架是前端的GWT + GWTP.

我们的第一个想法是让单个页面应用程序运行一个组合的GWT应用程序,其中功能是在主模块之外对齐的模块.

现在,我们正在实现我们实际创建系统功能的过程的关键阶段.但我们正面临着这种方法的严重问题.在这一点上,我们有41个GWT模块被编译为我们主模块的依赖关系,超过3GB的ram并需要8-12分钟.我们期望在当前开发阶段结束时拥有400多个模块,并且在编译应用程序的计算机能力方面将变得不可持续.

我们已经在http://www.summa-tech.com/blog/2011/02/22/structuring-gwt-modules-for-large-applications上看了一些像Ben Northrop的文章.但我们想就此事提出其他意见.