SpringSource dm 服务器偶尔无法解压有效的 ZIP 文件
将我的项目部署到 SpringSource dm Server 时，偶尔会有一个 JAR 无法部署，并显示以下消息：
/mnt/myproject/springsource/work/com.springsource.server.deployer/packed/my.project.0.1.10.M.jar' cannot be unpacked.
java.util.zip.ZipException: error in opening zip file
项目中有 5 个 .war 文件。如果其中之一失败，则始终是同一个（也是最后一个复制到拾取目录中的）。但是，通常所有 5 个都可以顺利部署。它是所有实例中完全相同的文件集，取自 Maven 存储库，刚刚部署到新的服务器实例。
失败的文件可以通过 7-Zip 正常打开。如果我停止Spring，清除pickup目录，启动Spring并再次将.war文件复制到pickup，它通常会起作用。
通常的部署过程是：
- 启动 Spring
- 等待，直到报告 Open for Business with profile 'web'
- 复制所有 5 个项目，每个副本之间有 2 秒的延迟（脚本化）。
类似问题 java-util-zip-zipexception-error-in- opening-zip-file 和 jboss5-cannot-deploy- due-to-java-util-zip-zipexception-error-in-opening-zip-fil 似乎不适用。
When deploying my project to SpringSource dm Server, every once in a while a JAR fails to deploy with the following message:
/mnt/myproject/springsource/work/com.springsource.server.deployer/packed/my.project.0.1.10.M.jar' cannot be unpacked.
java.util.zip.ZipException: error in opening zip file
There are 5 .war files in the project. If one of them fails, it's always the same one (which is also the last one to be copied into the pickup directory). However, usually all 5 will deploy without issues. It is the exact same set of files in all instances, taken from a maven repository, just deployed to new server instances.
The file that fails can be opened just fine by 7-Zip. If I stop Spring, clear the pickup directory, start Spring and copy the .war files to pickup again, it will usually work.
The usual deployment process is:
- Start Spring
- Wait until it reports Open for business with profile 'web'
- Copy all 5 projects with a 2 second delay between each copy (scripted).
Similar issues java-util-zip-zipexception-error-in-opening-zip-file and jboss5-cannot-deploy-due-to-java-util-zip-zipexception-error-in-opening-zip-fil do not seem to apply.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有说明您正在运行哪个版本的 dm Server，因此我建议您升级到 2.0.x 以获取修复程序（如果您还没有这样做）。您可能还想升级到 Eclipse Virgo，它是 dm Server 项目的延续。
我的猜测是，dm 服务器中用于确定文件复制到拾取器何时终止的启发式正在发挥作用，可能是由于复制操作缓慢或不稳定。您的磁盘是否存在任何异常情况，例如加密或远程挂载，这可能会干扰复制操作？
排除启发式的一种方法是在 dm Server 未运行时将文件放置在拾取目录中，然后在复制操作确实完成时启动 dm Server。如果问题再次出现，则您使用的 JRE 可能存在问题。
You don't say which version of dm Server you are running, so I would recommend upgrading to 2.0.x to pick up fixes if you haven't already. You may also like to upgrade to Eclipse Virgo which is the continuation of the dm Server project.
My guess is that the heuristic in dm Server for determining when a file copy into pickup has terminated is playing up, possibly due to a slow or irratic copy operation. Is there anything unusual about your disk, such as encryption or remote mount, which may interfere with the copy operation?
One way to rule out the heuristic would be to place the files in the pickup directory when dm Server is not running and then start dm Server when the copy operation has definitely completed. If the problem reproduces, then there may be a problem in the JRE you are using.