gpt4 book ai didi

java.util.zip.ZipFile.ensureOpenOrZipException 与 WAS 7

转载 作者:行者123 更新时间:2023-12-01 15:10:02 26 4
gpt4 key购买 nike

问题与此处描述的完全相同:

Exception java.util.zip.ZipFile.ensureOpenOrZipException with WAS 7

根据解决方案,我将应用程序模块更改为 2.4,并解决了该问题。我没有像决议中提到的那样更改wsdl的路径。但是一旦更改应用程序模块,就不会生成 webservices.xml 文件。我需要生成 xml 文件。

有人有任何替代解决方案来解决这个问题,而我不需要更改应用程序模块吗?

问候,

最佳答案

您提到的原始问题有两个部分。其中之一是关于 ZIPException。由于该异常是在 WebSphere 代码深处触发的,因此您不太可能在这里获得该问题的解决方案。您应该联系 IBM 支持人员来解决此问题。另一部分是关于内存问题。根据我使用部署在 WebSphere 上的 JAX-WS 服务(以及一般使用 WebSphere)的经验,我可以提出两个建议:

  1. 最初的问题说问题发生在“几次部署之后”。这表明存在类加载器泄漏。类加载器泄漏是一种特殊类型的内存泄漏,它会阻止应用程序的旧类加载器在重新部署或重新启动应用程序后被垃圾收集(有关更详细的描述,请参阅 here )。这可能是由应用程序或服务器运行时引起的。经验表明,WebSphere 本身存在多个导致此类泄漏的问题,而 IBM 在解决这些问题上通常效率不高。我曾经整理过一份我遇到过的此类已知 WebSphere 问题的列表。已发布here 。可以看到,基本上任何或多或少复杂的 Java EE 应用程序都会受到此类问题的影响。因此,您应该做好准备,当频繁重新部署而不重新启动服务器时,它最终会耗尽内存。

    注意:为了捍卫 IBM,应该说其他应用程序服务器在这方面不一定表现得更好。

  2. 在一种特殊情况下,部署在 WebSphere 上的 JAX-WS 服务可能会意外消耗大量内存。对于使用自上而下方法(即从 WSDL 开始)开发但具有不引用原始 WSDL 的 @WebService 注释的服务,会发生这种情况。在这种情况下,WebSphere(非常正确)认为它们是自下而上的服务,并根据 JAX-WS/JAXB2 注释生成 WSDL 和 XML 模式文档。这些文档保存在内存中,在某些情况下(特别是对于复杂的服务)可能比原始 WSDL 和 XML Schema 文档大得多。我曾经见过一个应用程序为此消耗了 200MB 的堆。为了避免这种情况,请确保在创建自上而下的 JAX-WS 服务时,将原始 WSDL 和 XML Schema 文档打包在应用程序中,并且服务实现具有正确引用这些的 @WebService 注释。文件。

关于java.util.zip.ZipFile.ensureOpenOrZipException 与 WAS 7,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12461623/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com