如何更正错误“java.util.zip.ZipException：在打开 zip 文件时出错”在 WAS 上使用 Portal 调用 Web 服务
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/25053124/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to correct the error 'java.util.zip.ZipException: error in opening zip file' invoking web service on WAS with Portal
提问by Dave ONeill
I have developed a web service for Portal 7.0 and deployed the application into an environment. The installation and start up of the application is fine, however, when the web service is invoked, the following error appears in the SystemOut.log a few hundred times. The server then starts reporting other errors about 'Too many open files' until the application is stopped or the services restarted.
我已经为 Portal 7.0 开发了一个 Web 服务并将应用程序部署到环境中。应用程序的安装和启动都很好，但是在调用Web服务时，SystemOut.log中出现了数百次以下错误。然后服务器开始报告有关“打开的文件太多”的其他错误，直到应用程序停止或服务重新启动。
[7/29/14 8:45:56:647 EST] 00000057 WSClassFinder E WSWS7058E: A JAXBContext could not be created correctly because of the following error: java.util.zip.ZipException: error in opening zip file
[7/29/14 8:45:56:647 EST] 00000057 WSClassFinder E WSWS7058E: A JAXBContext could not be created correctly because of the following error: java.util.zip.ZipException: error in opening zip file
Strange thing is we have a development and production environment that are basically identical (Same Linux OS version + WAS and Portal 7.0.0.23). Initially the web service worked fine in dev, but an attempt to use it in production failed (Not a good look). After rebooting dev, the problem started to occur there as well (at least it is now consistent).
奇怪的是，我们有一个基本相同的开发和生产环境（相同的 Linux OS 版本 + WAS 和 Portal 7.0.0.23）。最初 Web 服务在开发中运行良好，但尝试在生产中使用它失败了（看起来不太好）。重新启动 dev 后，问题也开始出现在那里（至少现在是一致的）。
I also tried to build the most basic of basic web service applications (it just returns a single static string) and even that failed with exactly the same result when invoked. I have a separate development environment where I do most of my work which is separate to the one above, but with the same app versions. This one has always worked fine. This suggests it is a configuration or server issue.
我还尝试构建最基本的基本 Web 服务应用程序（它只返回一个静态字符串），即使在调用时也以完全相同的结果失败。我有一个单独的开发环境，我在其中完成大部分工作，该环境与上述环境分开，但具有相同的应用程序版本。这个一直很好用。这表明这是配置或服务器问题。
I have used tracing on the com.ibm.ws.classloader and java.util.zip without any very useful information. Class loader didn't seem to clearly indicate the root of the problem and java.util.zip didn't report anything in the trace.
我在 com.ibm.ws.classloader 和 java.util.zip 上使用了跟踪，但没有任何非常有用的信息。类加载器似乎没有明确指出问题的根源，并且 java.util.zip 没有在跟踪中报告任何内容。
Unfortunately I'm stuck with where to look for options to correct this. It could be an OS file permissions problem, but its not clear where this may be. There is an upgrade of this environment planned, but because it was previously working on this build version (on the dev server) I'd really like to get to the root cause before pursuing the upgrade.
不幸的是，我被困在何处寻找解决此问题的选项。这可能是操作系统文件权限问题，但不清楚这可能在哪里。计划升级此环境，但因为它以前在此构建版本上工作（在开发服务器上），我真的很想在进行升级之前找到根本原因。
Any suggestions or pointers would be most appreciated.
任何建议或指示将不胜感激。
采纳答案by Dave ONeill
The suggestions about the open file limit restrictions were right all along, we were just looking in the wrong place. The 'default' ulimit settings were valid, but these are not the ones that are applied when the WebSphere Portal server is started via an init.d script. The very last section in this article identified the issue we were experiencing:
关于打开文件限制的建议一直是对的，我们只是找错了地方。“默认” ulimit 设置是有效的，但这些不是通过 init.d 脚本启动 WebSphere Portal 服务器时应用的设置。本文的最后一部分确定了我们遇到的问题：
http://www-01.ibm.com/support/docview.wss?uid=swg21469413
http://www-01.ibm.com/support/docview.wss?uid=swg21469413
We verified this was the case by using the details in this article:
我们通过使用本文中的详细信息验证了这种情况：
http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg21407889
http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg21407889
All that was required was the update the init.d script to include the line 'ulimit -n xxxxx' with our required limit. We had used the WASService scripts to generate the init.d script and thought that it shouldn't need further modification. Maybe we missed a point in the use of the WASService script that handles this.
所需要做的就是更新 init.d 脚本，以包含具有我们所需限制的“ulimit -n xxxxx”行。我们已经使用 WASService 脚本来生成 init.d 脚本并认为它不需要进一步修改。也许我们在使用处理此问题的 WASService 脚本时遗漏了一点。
回答by Stephen C
My understanding is this exception typically comes from the native code ZIP library; e.g. when your code attempts to open a ZIP file. (At least, that's the case for the examples that Google showed me.)
我的理解是这个异常通常来自本机代码 ZIP 库；例如，当您的代码尝试打开 ZIP 文件时。（至少，Google 向我展示的示例就是这种情况。）
It could be a file (or directory) permission issue, but I think that ought to throw an IOException(or a subclass). IMO, it is more likely that either the ZIP (or JAR / WAR / EAR / etc) file that the code is trying to open is corrupted / truncated, or (maybe) it is some variant that your JVM doesn't understand, or ... it is not a ZIP file at all.
这可能是一个文件（或目录）权限问题，但我认为应该抛出一个IOException（或一个子类）。IMO，更可能是代码尝试打开的 ZIP（或 JAR/WAR/EAR/etc）文件已损坏/截断，或者（可能）它是您的 JVM 无法理解的某些变体，或者...它根本不是 ZIP 文件。
Assuming that you know the pathname for the file, try reading it with your system's (non-Java) zip file utility. That should give you some clues.
假设您知道文件的路径名，请尝试使用系统的（非 Java）zip 文件实用程序读取它。那应该会给你一些线索。
