CODEWITHSUNDEEP
javaweb-serviceswebsphere-7
user182944
user182944

Reputation: 8067

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

The problem is exactly the same as described here:

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

Following the resolution, I changed my application module to 2.4 and it resolved the issue. I did not changed the path of wsdl as mentioned in the resolution. But once the application module is changed, the webservices.xml file is not getting generated. I need the xml file to be generated.

Anyone having any alternative solution to this problem where I do not need to change the application module?

Regards,

Upvotes: 0

Views: 126

Answers (1)

Andreas Veithen
Andreas Veithen

Reputation: 9154

The original question you are referring to has two parts. One is about the ZIPException. Since that exception is triggered deep down in the WebSphere code it is unlikely that you will get a solution for that problem here. You should contact IBM support for that. The other part is about memory issues. From my experience with using JAX-WS services deployed on WebSphere (and using WebSphere in general), I can make two recommendations:

  1. The original question says that the problem occurs "after few deployments". This poins to a class loader leak. A class loader leak is a particular kind of memory leak that prevents the old class loader of an application from being garbage collected after a redeployment or restart of the application (for a more detailed description, see here). This can be caused by the application or the server runtime. Experience shows that WebSphere itself has several issues that cause this type of leaks, and IBM is in general not very efficient in solving these issues. I once compiled a list of known WebSphere issues of this type that I have encountered. It is published here. One can see that basically any more or less complex Java EE application will be affected by this type of issue. Therefore you should be prepared for the fact that when redeploying frequently without restarting the server, it will eventually run out of memory.

    Note: In defense of IBM it should be said that other application servers don't necessarily perform better in this area.

  2. There is one particular case where JAX-WS services deployed on WebSphere may consume unexpectedly large amounts of memory. This occurs for services that have been developed using the top-down approach (i.e. starting from the WSDL), but that have @WebService annotations that don't refer to the original WSDL. In that case, WebSphere (quite correctly) believes that they are bottom-up services and generates WSDL and XML Schema documents based on the JAX-WS/JAXB2 annotations. These documents are kept in memory and in some cases (especially for complex services) may be significantly larger than the original WSDL and XML Schema documents. I've once seen an application that was consuming 200MB of heap just for that. To avoid this, make sure that when creating top-down JAX-WS services, you package the original WSDL and XML Schema documents in the application and that the service implementations have @WebService annotations that correctly refer to these documents.

Upvotes: 1

Related Questions