2012-09-17 2 views
0

WAS :java.util.zip.ZipFile.ensureOpenOrZipException 여기에 설명 된 문제는 정확히 같은 7

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

해상도에 따라, 나는 2.4에 내 응용 프로그램 모듈을 변경하고이 문제가 해결 . 나는 해상도에서 언급 한 wsdl의 경로를 변경하지 않았다. 그러나 일단 응용 프로그램 모듈이 변경되면 webservices.xml 파일이 생성되지 않습니다. 나는 xml 파일을 생성해야한다.

응용 프로그램 모듈을 변경할 필요가없는이 문제에 대한 대안이있는 사람은 누구입니까?

감사합니다.

답변

1

당신이 말하는 원래 질문에는 두 부분이 있습니다. 하나는 ZIPException입니다. 그 예외가 WebSphere 코드에서 매우 아래로 트리거되기 때문에 여기에서 그 문제에 대한 해결책을 얻지 못할 것입니다. 이를 위해 IBM 지원부에 문의하십시오. 다른 부분은 기억 문제에 관한 것입니다.

  1. 원래 질문은 문제가 "몇 배치 후"발생하는 것을 말한다는 WebSphere에 배포 JAX-WS 서비스를 사용하여 (그리고 일반적으로는 WebSphere 사용) 내 경험에서, 나는이 개 권고를 할 수 있습니다. 클래스 로더 누수가 발생합니다. 클래스 로더 누수는 특정 종류의 메모리 누수로, 응용 프로그램을 다시 배포하거나 다시 시작한 후에 응용 프로그램의 이전 클래스 로더가 가비지 수집되지 않도록합니다 (자세한 내용은 here 참조). 이는 응용 프로그램 또는 서버 런타임에 의해 발생할 수 있습니다. 경험에 따르면 WebSphere 자체에는 이러한 유형의 누수를 일으키는 몇 가지 문제가 있으며 IBM은 일반적으로 이러한 문제를 해결하는 데 효율적이지 않습니다. 필자가 만난이 유형의 알려진 WebSphere 문제점 목록을 컴파일했습니다. 간행물은 here입니다. 기본적으로 다소 복잡한 Java EE 애플리케이션이 이러한 유형의 문제의 영향을 받는다는 것을 알 수 있습니다. 따라서 서버를 다시 시작하지 않고 자주 재배포 할 경우 결국 메모리가 부족해질 수 있다는 사실에 대비해야합니다.

    참고 : IBM을 보호하기 위해 다른 응용 프로그램 서버가 반드시이 영역에서 더 나은 성능을 발휘한다고는 할 수 없습니다.

  2. WebSphere에 배치 된 JAX-WS 서비스가 예상치 않게 많은 양의 메모리를 소비하는 특별한 경우가 있습니다. 이는 하향식 접근 방식 (WSDL에서 시작)을 사용하여 개발되었지만 원본 WSDL을 참조하지 않는 주석이 @WebService 인 서비스에 대해 발생합니다. 이 경우 WebSphere는 상향식 서비스이며 JAX-WS/JAXB2 주석을 기반으로 WSDL 및 XML 스키마 문서를 생성한다고 생각합니다. 이러한 문서는 메모리에 보관되며 경우에 따라 복잡한 서비스의 경우 원래 WSDL 및 XML 스키마 문서보다 훨씬 클 수 있습니다. 한 번만 200MB의 힙을 사용하는 응용 프로그램을 보았습니다. 이를 방지하려면 하향식 JAX-WS 서비스를 만들 때 응용 프로그램에 원본 WSDL 및 XML 스키마 문서를 패키지로 만들고 서비스 구현에이 문서를 올바르게 참조하는 @WebService 주석이 있어야합니다.