自動配置中のTomcatが異常に詰まって死ぬ処理方法
9862 ワード
仕事の中でjavaシステムを開発しました.このシステムの機能はquartzタイミングでレポートを生成し、ユーザーはシステムにログインしてレポートを表示することです.IBM社にもこのようなシステムがあります.このシステムを開発する際、迅速な反復の要求を満たすために、jenkinsを導入プラットフォームとして実現するために、自動パッケージ導入の機能を実現する必要があります.Jenkinsは以下の方法で行う.まずjenkinsの付属機能でコードサーバにコードをキャプチャします. はmavenを呼び出してコンパイルする. antスクリプトを呼び出して、バックアップデプロイメントパッケージとデプロイメントパッケージの名前を変更します. jenkinsの付属機能を使用して、リモートtomcatサーバに配備されます.
ただし、リモートtomcatサーバを導入するたびに、次の問題が発生します.
サーバー部門の検査を経て、tomcatは正常に構成され、動作しています.その後、jenkinsのリモート導入プラグインにバグがあると思っていましたが、今日はマルチスレッドを勉強しているときに突然問題の原因を考えました.
このレポートのアーキテクチャはspring+quartz+hibernateです.システムはtomcatサーバに配備されています.tomcatが起動するとquartzのプライマリスケジューリングスレッドが起動し、このスケジューリングスレッドはタイミングタスクを実行します.実装方式はスレッドプールを通過する.そのためtomcatがオフの場合、quartzのタスクスレッドはオフになっていないため、tomcatはquartzのタスクスレッドが終了するのを待っていて、一定の時間以上待っていると、リモート配置に失敗します.
ネットで調べた資料は以下の方法で解決します.http://blog.sina.com.cn/s/blog_6f7d179e01017ox2.html
ただし、タスクスレッドを閉じる時間が長すぎると、リモート導入に失敗します.そこで私は次の方法を提供します.
独立したプロセスを使用してquartzのプライマリ・スレッドを起動します.たとえばshellでquartzのエントリクラスを起動します.スプリングにquartzを統合しないでください.これによりtomcatは起動クローズ時にquartzの影響を受けません.
ただし、リモートtomcatサーバを導入するたびに、次の問題が発生します.
Deploying C:\Users\Administrator\.jenkins\workspace\PLMReport_TST\PLMReport\target\Report.war to container Tomcat 7.x Remote
Redeploying [C:\Users\Administrator\.jenkins\workspace\PLMReport_TST\PLMReport\target\Report.war]
Undeploying [C:\Users\Administrator\.jenkins\workspace\PLMReport_TST\PLMReport\target\Report.war]
ERROR: Build step failed with exception
org.codehaus.cargo.container.ContainerException: Failed to undeploy [C:\Users\Administrator\.jenkins\workspace\PLMReport_TST\PLMReport\target\Report.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:140)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:178)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:990)
at hudson.FilePath.act(FilePath.java:968)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1047)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668)
at hudson.model.Run.execute(Run.java:1763)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Context /Report is defined in server.xml and may not be undeployed
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:566)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:480)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.undeploy(TomcatManager.java:420)
at org.codehaus.cargo.container.tomcat.Tomcat7xRemoteDeployer.performUndeploy(Tomcat7xRemoteDeployer.java:62)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:130)
... 17 more
org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Context /Report is defined in server.xml and may not be undeployed
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:566)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:480)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.undeploy(TomcatManager.java:420)
at org.codehaus.cargo.container.tomcat.Tomcat7xRemoteDeployer.performUndeploy(Tomcat7xRemoteDeployer.java:62)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:130)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:178)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103)
at hudson.FilePath.act(FilePath.java:990)
at hudson.FilePath.act(FilePath.java:968)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1047)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668)
at hudson.model.Run.execute(Run.java:1763)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Build step 'Deploy war/ear to a container' marked build as failure
サーバー部門の検査を経て、tomcatは正常に構成され、動作しています.その後、jenkinsのリモート導入プラグインにバグがあると思っていましたが、今日はマルチスレッドを勉強しているときに突然問題の原因を考えました.
このレポートのアーキテクチャはspring+quartz+hibernateです.システムはtomcatサーバに配備されています.tomcatが起動するとquartzのプライマリスケジューリングスレッドが起動し、このスケジューリングスレッドはタイミングタスクを実行します.実装方式はスレッドプールを通過する.そのためtomcatがオフの場合、quartzのタスクスレッドはオフになっていないため、tomcatはquartzのタスクスレッドが終了するのを待っていて、一定の時間以上待っていると、リモート配置に失敗します.
ネットで調べた資料は以下の方法で解決します.http://blog.sina.com.cn/s/blog_6f7d179e01017ox2.html
ただし、タスクスレッドを閉じる時間が長すぎると、リモート導入に失敗します.そこで私は次の方法を提供します.
独立したプロセスを使用してquartzのプライマリ・スレッドを起動します.たとえばshellでquartzのエントリクラスを起動します.スプリングにquartzを統合しないでください.これによりtomcatは起動クローズ時にquartzの影響を受けません.