Build stuck at "75% (Fetching files)"
I'm on RTC3 Ifix1.
I'm trying to setup an RTC build. My hope is that the first build will be slow, to extract everything from RTC. But the subsequent ones should be fairly fast, as it only needs to accept changes and update changed files.
When the second time the build starts, the "Progress" field shows "75% (Fetching files)" and stays there, with the "Estimated Completion" showing "in xx minutes", where xx decrease as time goes along.
I don't know what the build engine is doing, as there has been no change in the repository since the first build. Does it really take 20 mins for the build engine to realize that there has been no change? (Almost the same amount of time as the initial extract.)
Am I doing something wrong? This long wait makes it hard to test the build.
I'm trying to setup an RTC build. My hope is that the first build will be slow, to extract everything from RTC. But the subsequent ones should be fairly fast, as it only needs to accept changes and update changed files.
When the second time the build starts, the "Progress" field shows "75% (Fetching files)" and stays there, with the "Estimated Completion" showing "in xx minutes", where xx decrease as time goes along.
I don't know what the build engine is doing, as there has been no change in the repository since the first build. Does it really take 20 mins for the build engine to realize that there has been no change? (Almost the same amount of time as the initial extract.)
Am I doing something wrong? This long wait makes it hard to test the build.
Accepted answer
And it's getting worse... I'm using IBM JDK 6.
1. The waiting time gets longer and longer as I attempted more builds. It was 14 mins this morning. It now became 21mins. The time increased gradually, i.e. the "overdue" time got longer and longer.
2. During this long wait, the JBE javaw.exe process always uses about 50% of the CPU (2 core machine), and about 400MB memory. It's not clear what it could be doing.
3. The build finally reaches the actual build stage, by calling an ant script. And it ran out of memory. When running the exact same ant script in Eclipse on the same machine, the ant javaw.exe process uses no more than 100MB memory. In JBE build, the memory used by the ant java.exe process keeps growing, reaches 900MB, and eventually dies. (In both cases, there are occasional spawned java/javac processes that reach 200MB.)
The ant version is the same in Eclipse and JBE (1.7.1).
Thoughts?
Hi,
We recommend using the JDK that ships with the Eclipse client. In the case of the build system, you may not always have the client though. Just curious what operating system you're using and if you have a JDK 1.5 on the system that could be used to see if you get the same results? You can explicitly set the JDK to be used with the jbe by specifying the -vm option.
Brent Ulbricht
Developer/Lead - RTC Build
3 other answers
I'm on RTC3 Ifix1.
I'm trying to setup an RTC build. My hope is that the first build will be slow, to extract everything from RTC. But the subsequent ones should be fairly fast, as it only needs to accept changes and update changed files.
When the second time the build starts, the "Progress" field shows "75% (Fetching files)" and stays there, with the "Estimated Completion" showing "in xx minutes", where xx decrease as time goes along.
I don't know what the build engine is doing, as there has been no change in the repository since the first build. Does it really take 20 mins for the build engine to realize that there has been no change? (Almost the same amount of time as the initial extract.)
Am I doing something wrong? This long wait makes it hard to test the build.
Hi,
If you're not already, you could start the JBE with the -verbose option to see if that will print any additional statements that could give an indication of what is happening. One other thought, is there any chance that the 'Delete directory before loading' option in the build definition is checked?
Brent Ulbricht
Developer/Lead - RTC Build
Brent, thanks for the reply.
Just tried it, but it didn't seem to have done anything. Where is the additional information supposed to go? The log file has the exact same first 6 lines as before:
2011-04-01 11:00:58 running on host: ...
2011-04-01 11:00:58 Should build occur?
2011-04-01 11:00:58 Yes: Pre-build participant "com.ibm.team.build.jazzscm" would like to build.
2011-04-01 11:00:59 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-04-01 11:00:59 Accepting changes into workspace ...
2011-04-01 11:01:00 Fetching files to fetch destination ...
2011-04-01 11:15:25 Invoking build participant "com.ibm.team.build.ant"
You can see the 14min gap between "fetching" and "invoking", while there is nothing to fetch.
It is not checked.
I was watching the file system on the build engine during the "fetching". All the files extracted from the previous build were not touched. The timestamp on files in .jazz5 got updated from time to time. That's the only activity as far as I can tell.
Any other suggestions?
BTW, what happens if the previous build changed some files or added some new files/folders in the extract folder? Will the new build leave them, merge them, delete them? Is it possible that JBE is spending time looking for those local changes?
If you're not already, you could start the JBE with the -verbose option to see if that will print any additional statements that could give an indication of what is happening.
Just tried it, but it didn't seem to have done anything. Where is the additional information supposed to go? The log file has the exact same first 6 lines as before:
2011-04-01 11:00:58 running on host: ...
2011-04-01 11:00:58 Should build occur?
2011-04-01 11:00:58 Yes: Pre-build participant "com.ibm.team.build.jazzscm" would like to build.
2011-04-01 11:00:59 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-04-01 11:00:59 Accepting changes into workspace ...
2011-04-01 11:01:00 Fetching files to fetch destination ...
2011-04-01 11:15:25 Invoking build participant "com.ibm.team.build.ant"
You can see the 14min gap between "fetching" and "invoking", while there is nothing to fetch.
One other thought, is there any chance that the 'Delete directory before loading' option in the build definition is checked?
It is not checked.
I was watching the file system on the build engine during the "fetching". All the files extracted from the previous build were not touched. The timestamp on files in .jazz5 got updated from time to time. That's the only activity as far as I can tell.
Any other suggestions?
BTW, what happens if the previous build changed some files or added some new files/folders in the extract folder? Will the new build leave them, merge them, delete them? Is it possible that JBE is spending time looking for those local changes?
And it's getting worse... I'm using IBM JDK 6.
1. The waiting time gets longer and longer as I attempted more builds. It was 14 mins this morning. It now became 21mins. The time increased gradually, i.e. the "overdue" time got longer and longer.
2. During this long wait, the JBE javaw.exe process always uses about 50% of the CPU (2 core machine), and about 400MB memory. It's not clear what it could be doing.
3. The build finally reaches the actual build stage, by calling an ant script. And it ran out of memory. When running the exact same ant script in Eclipse on the same machine, the ant javaw.exe process uses no more than 100MB memory. In JBE build, the memory used by the ant java.exe process keeps growing, reaches 900MB, and eventually dies. (In both cases, there are occasional spawned java/javac processes that reach 200MB.)
The ant version is the same in Eclipse and JBE (1.7.1).
Thoughts?
1. The waiting time gets longer and longer as I attempted more builds. It was 14 mins this morning. It now became 21mins. The time increased gradually, i.e. the "overdue" time got longer and longer.
2. During this long wait, the JBE javaw.exe process always uses about 50% of the CPU (2 core machine), and about 400MB memory. It's not clear what it could be doing.
3. The build finally reaches the actual build stage, by calling an ant script. And it ran out of memory. When running the exact same ant script in Eclipse on the same machine, the ant javaw.exe process uses no more than 100MB memory. In JBE build, the memory used by the ant java.exe process keeps growing, reaches 900MB, and eventually dies. (In both cases, there are occasional spawned java/javac processes that reach 200MB.)
The ant version is the same in Eclipse and JBE (1.7.1).
Thoughts?