检查SVN进行修改时,Cruisecontrol会挂起

时间:2009-10-26 13:00:46

标签: java svn cruisecontrol

自从将Cruisecontrol构建服务器迁移到新计算机后,它有时会在构建周期的“修改集”阶段挂起(它配置为每15分钟检查一次修改)。 Cruisecontrol本身保持响应,只有构建不会进展。

当发生这种情况时,CPU上没有明显的负载,并且我已经看到它在这种状态下保持了一个小时或更长时间,尽管它似乎最终会突破这种状态。似乎没有一种模式可以解决它发生的项目。硬件是全新的,我运行了一个没有问题的memtest。

这是系统配置:

  • Ubuntu 9.04服务器,amd64,完全升级
  • svn 1.5.4版(r33841) - 最新版本apt-get将安装
  • Sun JRE 64位版本1.6.0_16-b01 - 再次,最新版本
  • CruiseControl 2.7.3(不是最新的)

这就是我的修改集的样子

<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>

那么可以在这做什么?

编辑:以下是巡航控制日志文件的摘录,显示projectA在16:07挂起(现在仍在17:48挂起)

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

3 个答案:

答案 0 :(得分:2)

另一个想法。您始终可以在调试模式下启动CruiseControl JVM。每当它挂起时,使用某些IDE连接到它,例如日食。然后你可以使用CC应用程序的所有线程,并暂停其中一些,看看他们忙什么。

答案 1 :(得分:1)

您是否尝试过从命令行手动发出相同的SVN命令?它会挂起吗?

答案 2 :(得分:1)

只是一些指示:

  1. 它是否在一天的特定时间挂起?还是真的随意?是否有任何新的备份可以关闭备份服务?

  2. 您是否将新巡航服务器的config.xml与旧巡航服务器的config.xml进行了比较(假设巡航版本在两者上都相同,他们是否具有完全相同的任务,或者有什么可能会减慢修改集任务)?

  3. 旧机器和新机器是否与您的subversion存储库位于同一网络上(或者至少它们在访问所有项目存储库时的响应时间是否相似?)鉴于巡航服务器本身仍保持响应,是吗?在接近挂起时,它可能正在访问的特定项目仓库是否太大,太慢或者在存储库中进行了太多操作?

  4. 这些只是故障排除指针 - 因此它们绝不是您问题的实际答案。这可能是我解决问题的方法(除了在GrzegorzOledzki的回答中手动运行命令)。