Tomcat 6 是否已准备好进行持续集成或如何使其发挥作用？
我正在寻找如何使 tomcat CI 准备就绪或 servlet 容器/应用程序容器的提示，这些容器经常重新部署，就像使用 hudson ci 时发生的那样。
我发现 Tomcat 6 无法正确取消部署 webapp，将类留在 jvm 中。
例如，我使用 VisualVM 监控 tomcat 6：在启动 2000 个类时，在重新部署 4000 个和重新部署 5000 个类之后部署应用程序 3000 时，等等 - 导致崩溃、内存泄漏...
好吧，希望有人对 tomcat 和连续的有提示-集成或其他应用程序服务器。
I'm looking for a hint how to make tomcat CI ready or an servlet container / application container which stand often redeploys like they happen when using hudson ci.
I experienced that Tomcat 6 does not properly undeploy webapps, leaving classes in jvm.
For example I monitored tomcat 6 with VisualVM: on start 2000 classes, on deploy of an app 3000 after redeploy 4000 and redeploy 5000 classes and so on - leading to crashes, memory leaks...
Okay hope one have a hint on tomcat and continuous-integration or other app servers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更新：我使用 Spring、Hibernate、GWT、C3P0 和 HsqlDB 对一个中等复杂的 Web 应用程序进行了一些测试。
如果您使用客户端编译器，Stock Tomcat 6.0.24 就可以正常工作。它可以在十次重新部署后正常工作，而服务器编译器在第四次重新部署时就会崩溃。我建议您尝试使用
-client标志。尝试调试服务器编译器的使用是没有结果的，因为 Eclipse MAT 显示类加载器没有 GC 根，但它们仍然被保留。据报道，一个经常引用的错误，PermHeap 膨胀仅在服务器虚拟机中在 Java 6 update 16 中已修复，但我的测试在 Java 6 update 16 中失败。
Tomcat 已针对此类内存问题进行了反复检查，并且通常应归咎于应用程序。不，这并不是说这样的永久代泄漏一定很难。
这里有两种可能性：
如果你确实想调试这个问题并确保这是 Tomcat 的错，你可以使用 Eclipse 内存分析器 。他们有一篇很好的博客文章解释了如何调试 PermGen 问题。
Update : I've performed some tests with a moderately complex web application using Spring, Hibernate, GWT, C3P0 and HsqlDB.
Stock Tomcat 6.0.24 works just fine , provided you use the client compiler. It works on ten redeploys, whereas the server compiler breaks down on the fourth. I suggest you try with the
-clientflag.Trying to debug the usage of the server compiler was fruitless, as the Eclipse MAT showed no GC roots for the classloaders, and yet they were retained. An oft-referenced bug , PermHeap bloat in and only in server VM was reportedly fixed in Java 6 update 16, but my tests fail with Java 6 update 16.
Tomcat has been checked and double-checked for such memory problems, and quite often the applications were to blame. No that is not to say that it's necessarily hard to have such a perm gen leak.
There are two possibilities here:
If you actually want to debug this problem and make sure that it's Tomcat's fault, you can you the Eclipse memory analyser. They have a good blog post explaining how to debug PermGen problems.
我总是喜欢采取严厉的措施来确保启动时一切都是干净的并且处于完全可重现的状态
1) 杀死 tomcat
2) 从磁盘中删除它
3) 解压缩干净的版本
4) 覆盖您的个性化版本修改配置文件
5) 重新启动 tomcat
6) 部署您的应用程序
I always like to take drastic measures to make sure that everything is clean and in a fully reproducible state when starting
1) kill tomcat
2) delete it from disk
3) unzip a clean version
4) overwrite your personalized modified configured files
5) restart tomcat
6) deploy your app
看看 Apache Cactus - 它是一个服务器端框架容器内单元测试。它几乎适用于任何 servlet 容器。
Take a look at Apache Cactus - it's a framework for server-side in-container unit testing. It works pretty much with any servlet container.