java 在 Tomcat 上部署战争需要很长时间
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1790474/
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
War deployment on Tomcat takes ages
提问by Thody
I have a Grails application, built to a war file (~30mb). When I attempt to deploy the war file on Tomcat 6 via the application manager, it takes upwards of 10 minutes to deploy, or hangs indefinitely. When it hangs I can restart Tomcat and the app is usually deployed, however sometimes I have to repeat the process. I've also noticed that during deployment, the Java process maxes out the CPU and the RAM is at ~10-15%.
我有一个 Grails 应用程序，内置到一个War文件 (~30mb)。当我尝试通过应用程序管理器在 Tomcat 6 上部署 war 文件时，部署时间超过 10 分钟，或者无限期挂起。当它挂起时，我可以重新启动 Tomcat 并且通常会部署该应用程序，但是有时我必须重复该过程。我还注意到，在部署过程中，Java 进程将 CPU 最大化，而 RAM 为 ~10-15%。
I'm fairly new to Java, so I don't know if this is normal, but I can't imagine how it could be. Is there something I can do to make this run smoother/faster? Is there a better way to deploy than Tomcat's app manager?
我对 Java 还很陌生，所以我不知道这是否正常，但我无法想象它是怎么回事。有什么我可以做的让这个运行更顺畅/更快吗？有没有比 Tomcat 的应用程序管理器更好的部署方式？
采纳答案by Kaleb Brasee
I upload the WAR to my home directory, cd to /usr/local/tomcat, then run the following commands:
我将 WAR 上传到我的主目录，cd 到 /usr/local/tomcat，然后运行以下命令：
bin/shutdown.sh
rm webapps/ROOT.war
rm -rf webapps/ROOT
cp ~/ROOT.war webapps
bin/startup.sh
回答by Karl
As noted I would copy the war to the webapps folder and let tomcat do the deployment, its also quicker saving you time.
如前所述，我会将 war 复制到 webapps 文件夹并让 tomcat 进行部署，这也可以更快地节省您的时间。
Both Tomcat and Jetty will support a hot deploy. They simply monitor the deploy directory for changes, so you can just copy the .war file into that directory, and the server will undeploy/redeploy.
Tomcat 和 Jetty 都将支持热部署。他们只是监视部署目录的更改，因此您只需将 .war 文件复制到该目录中，服务器就会取消部署/重新部署。
If using a remote server check the lag is not the time take to upload the war to a remote server over the network.
如果使用远程服务器，请检查延迟不是通过网络将War上传到远程服务器所花费的时间。
回答by BalusC
Definitely check the Tomcat logs for any errors/warnings.
一定要检查 Tomcat 日志是否有任何错误/警告。
You probably have some expensive/sensitive code logic in one of the ServletContextListeners. They are usually initialized during startup. If so, then I would debug/profile it for any performance matters/leaks.
您可能在其中一个中有一些昂贵/敏感的代码逻辑ServletContextListener。它们通常在启动期间初始化。如果是这样，那么我会针对任何性能问题/泄漏对其进行调试/分析。
回答by Trick
Don't use application manager. My way is to upload it somewhere out of the webapps directory and then copy it to webapps directory. Takes a lot less of deplyoment time.
不要使用应用程序管理器。我的方法是将它上传到 webapps 目录之外的某个位置，然后将其复制到 webapps 目录。花费更少的部署时间。
回答by Gruber
It's not always that you have sufficient access rights to manually put files in the webappsfolder -- you are supposed to use the Tomcat Application Manager for .warfile deployment, and need to make it work.
您并不总是有足够的访问权限来手动将文件放入文件webapps夹——您应该使用 Tomcat 应用程序管理器进行.war文件部署，并且需要使其工作。
For me, it has been common that the process of uploading of a .warfile to the server cannot complete; it gets stuck somewhere in the middle and the file is only partially uploaded to the server, no matter how many times I retry. In such situations, I have found it worthwhile to try another browser. For instance, I've found myself stuck using Google Chrome but once I switched to a freshly started Firefox browser, things worked out.
对我来说，将.war文件上传到服务器的过程无法完成是很常见的；它卡在中间的某个地方，无论我重试多少次，文件都只是部分上传到服务器。在这种情况下，我发现尝试其他浏览器是值得的。例如，我发现自己一直在使用 Google Chrome，但是一旦我切换到新启动的 Firefox 浏览器，事情就解决了。
回答by Tu?n Lé
This may be relate to this BUG of JDK
I readed this article, Tomcat7 starts too late on Ubuntu 14.04 x64and resolved my problem.
我读了这篇文章，Tomcat7 在 Ubuntu 14.04 x64 上启动太晚并解决了我的问题。
Try to resolve it by Replacingsecurerandom.source=file:/dev/urandom with securerandom.source=file:/dev/./urandom in $JAVA_PATH/jre/lib/security/java.security
尝试通过在 $JAVA_PATH/jre/lib/security/java.security 中用 securerandom.source=file:/dev/./urandom替换securerandom.source=file:/dev/urandom来解决它
