com.ibm.team.build.common.TeamBuildException: CRRTC3505E
In our project we have 4 build engines (windows 7, vista, XP) running 3 different PDE builds.
Most of the time everything works like a charm. However, we occasionally run into the following error: com.ibm.team.build.common.TeamBuildException: CRRTC3505E: Unable to delete fetch destination This sometimes doesn't occur for several builds (maybe a day or so) but then for no apparent reason a build will suddenly fail with aforementioned error. I have logged on to the corresponding build engine and had a look at the fetch destination directory. Sometimes only a set of empty folders is left, another time 2 or 3 non-empty folders may still exist (the build engine has happily deleted the other 300 MB w/o complaining). I can delete whatever has been left over by the build engine and then re-request the same build and that will run w/o further errors. Thus, it doesn't seem like a rogue process still has an open file handle and is blocking the deletion. Any ideas what might be going on here? |
15 answers
We have seen this problem intermittently. This example is from a test build which simply accepts changes, deletes the destination, fetches files, and runs a Windows batch file that just does one "echo" command to output a message to stdout.
From a failed build: 2012-02-10 22:25:17 Accepting changes into workspace "eanderso Beetle (WPF 8.0.0) buildws2" ... 2012-02-10 22:25:23 Deleting fetch destination "C:\temp\B_WEF8.0_CHKPT_2" before fetching ... com.ibm.team.build.common.TeamBuildException: CRRTC3505E: Unable to delete fetch destination "C:\temp\B_WEF8.0_CHKPT_2". at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:218) at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:844) at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:650) at java.lang.Thread.run(Thread.java:811) The next build was ok: 2012-02-10 22:40:00 Accepting changes into workspace "eanderso Beetle (WPF 8.0.0) buildws2" ... 2012-02-10 22:40:01 Deleting fetch destination "C:\temp\B_WEF8.0_CHKPT_2" before fetching ... 2012-02-10 22:40:01 Fetching files to fetch destination "C:\temp\B_WEF8.0_CHKPT_2" ... 2012-02-10 22:53:55 Invoking build participant "com.ibm.team.build.cmdline" 1) What version of JBE are you using? 3.0.1 2) How is the build definition set-up; how are you starting the build? This was a scheduled build. 3) Can you confirm that there are not two engines running on the same machine (using the same load directory) There is only one build engine on this machine. 4) Does this happen all the time for you? If not, how often? (can you think of anything different about the setup/build when this does happen?) It is intermittent. We have not detected a pattern to when it happens. This build ran about 20 times before one failed, and ran ok another 20 times after the one that failed. 5) Is there any time where a next build would be able to delete the directory properly, or once it happens, do all future builds fail to delete the directory? The next build deletes the directory ok. 6) If a build fails to delete the load directory (with JBE and the build loop still running, but not building anything) are you able to manually delete the directory? This may indicate that something in JBE has locks on some files in the directory. If that doesn't work, can you kill JBE and then try to manually delete the file? We haven't examined the load directory before the next build runs and deletes it. Will test this if we get the chance. 7) Are there any build scripts , or forked off programs/executable that do work on this load directory? Yes in our normal builds, but in this example the build script does nothing with the load directory. 8) What files are left over when the build fails. Is it always the .jazz folder? or is it always some other folders / files , or does it appear completely random? Unknown. See #6 above. 9) What is the operating system, and where/how is the load directory specified ("relative" , or are you using an "absolute" path?). In this example: Windows 7, absolute path. |
On 2/11/2012 6:53 PM, gpflaum wrote:
2012-02-10 22:25:23 Deleting fetch destination On my Windows 7 development machine, I sometimes get an error when trying to delete a directory tree through Windows Explorer, and tools that I use sometimes report errors trying to delete a directory tree. In every case, I can successfully delete the directory the next time I try. I have concluded (without having hard evidence to back it up) that it is a bug in the Windows 7 file system. -- David Olsen IBM Rational Beaverton, Oregon |
|
I got a chance to look at the build area after this error, so here's some more information to add to my previous reply.
8) What files are left over when the build fails. Is it always the .jazz folder? or is it always some other folders / files , or does it appear completely random? There was only one folder, empty, in the build area, and no files: C:\temp\B_WEF8.0_CHKPT_2\factory\lwp\Designer\designer.nls\nl In the stream, that folder has 8 subfolders, two of which have 1 more folder, but the stream has no files in the nl folder, just the empty subfolders. The build area was left from the last time I ran the jbe, a few days ago. I rebooted since then, and started the jbe which got this error on the first build. The timestamps on the "nl" folder showed it was created a few days ago, the previous time the build ran, and it was modified today, at the time the build failed. |
I know this is an old post, but I still get this exception for some of the scheduled builds.
Has anyone found the reason for this exception and how to fix the problem?
|
I had the same problem, and probably the cause was zombie build engine process/thread.
Solution was to kill jbe process (find with ps -ef | grep jbe and kill -9 resulting pid) on build machine and restart build engine. After that build works well. wrote about it here |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.