See http://hudson.361315.n4.nabble.com/ClearCase-error-after-user-canceled-previous-update-td2242261.html for the complete thread.

A user canceled a job while it was in the middle of updating the view:

Processing dir "xxx\domain\dev\config\com\xxx\spr\domain\search".
......SCM check out aborted
Recording test results
..ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at hudson.remoting.Request.call(Request.java:122)
at hudson.remoting.Channel.call(Channel.java:551)
at hudson.FilePath.act(FilePath.java:742)
at hudson.FilePath.act(FilePath.java:735)
at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:83)
at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122)
at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:133)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:580)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:558)
at hudson.model.Build$RunnerImpl.post2(Build.java:158)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528)
at hudson.model.Run.run(Run.java:1264)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:124)
Email was triggered for: Failure
Sending email for trigger: Failure
Sending email to: [hidden email]
Finished: FAILURE

The job is marked as a failure, which isn't unexpected. So far, so good.

However, now ClearCase always thinks that this job's view is in the middle of an update, so subsequent runs fail:

Started by an SCM change
Building remotely on NODE5
[NODE5_jobx] $ cleartool pwv -root
C:\Hudson\workspace\jobx\NODE5_jobx
[jobx] $ cleartool lsview NODE5_jobx
NODE5_jobx \\NODE5\view\viewdb\NODE5_jobx
[NODE5_jobx] $ cleartool lsview -cview -s
NODE5_jobx
[jobx] $ cleartool catcs -tag NODE5_jobx
element * CHECKEDOUT
element * .../viewx_dev/LATEST
mkbranch viewx_dev
element * .../viewx/LATEST
element * IH_REL1234
element * /main/LATEST
load \xxx
[NODE5_jobx] $ cleartool update -force -overwrite -log NUL
cleartool: Warning: An update is already in progress for view "C:\Hudson\workspace\jobx\NODE5_jobx".
Started by 'rsteele@NODE5' (process 2064) on 6/2/2010 2:46:36 PM
Continue, terminating the previous update session? [no] FATAL: java.io.IOException: View update failed: cleartool: Warning: An update is already in progress for view "C:\Hudson\workspace\jobx\NODE5_jobx".
Started by 'rsteele@NODE5' (process 2064) on 6/2/2010 2:46:36 PM
Continue, terminating the previous update session? [no]
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
Sending email to: [hidden email]
Finished: FAILURE

I believe this is the correct behavior on Hudson's part: it thinks an update is already in progress so to be safe it fails the build. The problem is that the view is forever wedged in this state.

I'm wondering if this has something to do with how the original update was aborted. Is there a way to make sure the view is clean after the abort?

I'm running Hudson 1.360 with Windows XP master and slaves, using version 1.2 of the ClearCase plugin with Base ClearCase 7.0.

Thanks,
Rich