SVNの変更をチェックするときにCruisecontrolがハングする

Question

Cruisecontrolビルドサーバーを新しいマシンに移行してから、ビルドサイクルの「変更セット」段階（15分ごとに変更をチェックするように構成されている）でハングすることがあります。 Cruisecontrol自体は応答性があり、ビルドだけが進行しません。

CPUに重大な負荷はなく、最終的にはこの状態から脱出するように見えますが、1時間以上この状態に留まっています。それは起こっているプロジェクトのパターンではないようです。ハードウェアはまったく新しいもので、問題なくmemtestを実行しました。

この

は、システム構成です：

• のUbuntu 9.04サーバー、AMD64、完全にアップグレード
• SVNバージョン1.5.4（r33841） - 最新バージョンのapt-getを
• 日JREをインストールしますこれは、HOで再び、最新のバージョン
• CruiseControlの2.7.3（最新ではない）

を - 64ビット1.6.0_16-b01を構築w私の修正セットは次のようになります

<modificationset quietperiod="10"> 
    <veto><!-- there are several of these --> 
     <triggers> 
      <svn LocalWorkingCopy="${checkout_dir}/base" /> 
     </triggers> 
     <buildstatus logdir="${log_dir}/base" /> 
    </veto> 
    <timebuild time="2330" /> 
    <svn LocalWorkingCopy="${checkout_dir}/${project.name}" /> 
</modificationset> 

ここで何ができますか？

編集：ここではは（それはまだ夜5時48分で、今ぶら下がっている）午前16時07分にぶら下がっPROJECTAを示す、CruiseControlのログファイルからの抜粋です

2009-10-27 16:07:55,096 [Thread-38860] INFO Project   - Project projectA: bootstrapping 
2009-10-27 16:07:55,096 [Thread-38860] INFO ProjectController - projectA Controller: build progress event: bootstrapping 
2009-10-27 16:07:55,262 [Thread-38862] INFO ScriptRunner  - Buildfile: work/build-cruisecontrol.xml 
2009-10-27 16:07:59,230 [Thread-38860] INFO AntBootstrapper - Bootstrap successful. 
2009-10-27 16:07:59,230 [Thread-38860] INFO Project   - Project projectA: checking for modifications 
2009-10-27 16:07:59,230 [Thread-38860] INFO ProjectController - projectA Controller: build progress event: checking for modifications 
2009-10-27 16:11:14,954 [Project projectB thread] INFO Project   - Project projectB: in build queue 

Answer 1

あなたは同じSVNコマンドを発行しようとしたことがあり手動でコマンドラインから？それはその後ハングアップしますか？

Answer 2

はいくつかのポインタ：

1. それは一日の特定の時間にハングアップしていますか？それとも本当にランダムですか？バックアップのためにサービスをシャットダウンする新しいバックアップ

2. 新しいクルーズサーバーのconfig.xmlと古いクルーズサーバーのconfig.xmlを比較しましたか（クルーズバージョンが両方で同じであると仮定しているか、まったく同じタスクを持っているか、仕事）？

3. 古いマシンと新しいマシンは、Subversionリポジトリと同じネットワークに置かれていますか（または少なくとも、すべてのプロジェクトリポジトリにアクセスするのに似た応答時間を持っていますか？）クルーズサーバー自体が応答可能なままであればニア・ハング時にアクセスしている特定のプロジェクト・リポジトリが大きすぎる、遅すぎる、リポジトリ内であまりにも多く実行されていることなどがあります。

これは単なるトラブルシューティングのポインタなので、実際の質問に対する回答ではありません。これはおそらく私が問題にアプローチする方法です（GrzegorzOledzkiの答えのように手動でコマンドを実行する以外に）。

Answer 3

別のアイデア。 CruiseControl JVMはいつでもデバッグモードで起動できます。ハングアップするたびに、いくつかのIDEを使用して接続します。 Eclipse。そして、あなたはCCアプリケーションのすべてのスレッドを実行して、それらのいくつかを一時停止し、彼らが何を忙しくしているかを見てください。