
| Key: |
CC-431
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
John Lewis
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
File Attachments:
|
1.
patchfile.txt (3 kb)
|
|
Environment:
|
All
|
|
|
I would like to submit a bug fix.
Description of bug:
Force a build while it is running. After the build finishes, it will go "in build queue" and never leave. The thread assigned to build it is never used again. If you are using only one thread, all projects will eventually go "in build queue". You have to restart cruisecontrol to get out of this state.
This bug was introduced with rev 1.94 of net.sourceforge.cruisecontrol.Project. If buildForced, the state does not go to WAITING. It goes to QUEUED. The net.sourceforge.cruisecontrol.ProjectWrapper checks the state to see if the build is finished. Since it never sees the state as WAITING, it never thinks the build has finished.
void waitForNextBuild() throws InterruptedException {
long waitTime = getTimeToNextBuild(new Date());
if (needToWaitForNextBuild(waitTime) && !buildForced) { <-------------
info("next build in " + DateUtil.formatTime(waitTime));
synchronized (waitMutex) {
setState(ProjectState.WAITING);
waitMutex.wait(waitTime);
}
}
}
Fix:
Improve the net.sourceforge.cruisecontrol.ProjectWrapper.doneBuilding() method. Instead of checking the state of the wrapped project, just keep track of a boolean and set it to true after the wrapped project's execute() returns.
This fix has been reviewed by Jared Richardson who originally submitted ProjectWrapper.
The change has been tested on three platforms with an internal version of cruisecontrol: Solaris 9, Red Hat Linux ES 3, Windows Server 2003.
|
|
Description
|
I would like to submit a bug fix.
Description of bug:
Force a build while it is running. After the build finishes, it will go "in build queue" and never leave. The thread assigned to build it is never used again. If you are using only one thread, all projects will eventually go "in build queue". You have to restart cruisecontrol to get out of this state.
This bug was introduced with rev 1.94 of net.sourceforge.cruisecontrol.Project. If buildForced, the state does not go to WAITING. It goes to QUEUED. The net.sourceforge.cruisecontrol.ProjectWrapper checks the state to see if the build is finished. Since it never sees the state as WAITING, it never thinks the build has finished.
void waitForNextBuild() throws InterruptedException {
long waitTime = getTimeToNextBuild(new Date());
if (needToWaitForNextBuild(waitTime) && !buildForced) { <-------------
info("next build in " + DateUtil.formatTime(waitTime));
synchronized (waitMutex) {
setState(ProjectState.WAITING);
waitMutex.wait(waitTime);
}
}
}
Fix:
Improve the net.sourceforge.cruisecontrol.ProjectWrapper.doneBuilding() method. Instead of checking the state of the wrapped project, just keep track of a boolean and set it to true after the wrapped project's execute() returns.
This fix has been reviewed by Jared Richardson who originally submitted ProjectWrapper.
The change has been tested on three platforms with an internal version of cruisecontrol: Solaris 9, Red Hat Linux ES 3, Windows Server 2003.
|
Show » |
|