[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: Text File basicPlus (1).txt     Text File basicPlus.txt    
Operating System: ALL
Participants:

 Description   

http://buildlogs.mongodb.org/Nightly%20Windows%2064-bit%202008%2B%20DEBUG/builds/251/test/parallel/basicPlus.js
http://buildlogs.mongodb.org/Nightly%20Windows%2064-bit%20DEBUG/builds/252/test/parallel/basicPlus.js



 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:

  • 5bbdfa31eba4680f8aee37300db852706b9289cb: first change before Interlocked changes, passed in my testing
  • d3aef09798f59763f268a3e9ad35d0ddca1b7018: Interlocked changes, passed in my testing

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.

Generated at Thu Feb 08 03:18:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.