[SERVER-8759] basicPlus.js timing out on Windows DEBUG builds Created: 27/Feb/13 Updated: 08/Mar/13 Resolved: 06/Mar/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Whalen (Inactive) | Assignee: | Tad Marshall |
| Resolution: | Done | Votes: | 0 |
| Labels: | buildbot | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Participants: |
| Description |
| Comments |
| Comment by Tad Marshall [ 28/Feb/13 ] |
|
I would take a different approach to this timeout. I would try to find what tests are taking excessive time and then make those tests check for Windows debug builds and do less work so that they don't take so long. The parallel tests run four threads at the same time, with a random set in each thread. This means that if two tests are both slow in debug builds on Windows, they will sometimes end up on different threads and so overlap in time. If they both get assigned to the same thread, they will run sequentially, which can trigger the timeout. The best way to prevent this is to reduce the duration of the slowest tests, in my opinion. |
| Comment by Andrew Morrow (Inactive) [ 28/Feb/13 ] |
|
I started looking into this because I was concerned that my recent changes to Windows Interlocked support could have been problematic. I ran the test basicPlus test at four different commits for a rough manual bisect:
Bad news is that the test appears to be flaky, which means I can't really trust my single runs of the test at the earlier commits. One possibility would be to set up a script to do repeated runs of the test with proper 'git bisect' error reporting and let git bisect go to town. That is going to take a long time though. |