[SERVER-64323] windows ldap tests failing with concurrency Created: 08/Mar/22 Updated: 29/Oct/23 Resolved: 10/Jun/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Moody | Assignee: | Sergey Galtsev (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Security 2022-05-16, Security 2022-05-30, Security 2022-06-13 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The jobs for resmoke tests on windows for external auth suite were limited in |
| Comments |
| Comment by Githook User [ 10/Jun/22 ] | |||||||||||
|
Author: {'name': 'sergey.galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}Message: | |||||||||||
| Comment by Sergey Galtsev (Inactive) [ 07/Jun/22 ] | |||||||||||
|
Plan to go forward is: 1. Windows will be running in single test mode, Linux will run multiple | |||||||||||
| Comment by Sergey Galtsev (Inactive) [ 02/Jun/22 ] | |||||||||||
|
I opened | |||||||||||
| Comment by Billy Donahue [ 23/May/22 ] | |||||||||||
|
Abseil does something that might help with the startup cost?
| |||||||||||
| Comment by Sergey Galtsev (Inactive) [ 23/May/22 ] | |||||||||||
|
There is a fix available, however it is not possible to reliably verify it within our present test harness. While discussing situation with andrew.morrow@mongodb.com and matt.broadstone@mongodb.com, we decided to put the ticket on a back-burner up until the windows stack trace functionality testing is implemented. Linking to PM-2926, and must be revisited once a ticket is raised to verify specifically windows stack trace generation | |||||||||||
| Comment by Sergey Galtsev (Inactive) [ 20/May/22 ] | |||||||||||
|
The difference between VS2019 and VS2022 builds was identified: SymInitializeW will take ~0.6 sec on VS2019 builds, and ~1.5 sec on VS2022. That seems to match tests in which mongod starting up and then immediately shutting down exhibited difference in run time of ~1 sec. After commenting out SymbolHandler initialization code, I tried running external_auth 6 times in attempt to reproduce failures, and it was successful every time | |||||||||||
| Comment by Sergey Galtsev (Inactive) [ 12/May/22 ] | |||||||||||
|
This is preliminary report on the subject, which I am posting to summarize what I found so far. I have not at this time found root cause for any of the issues described Setting:Distro: windows-vsCurrent-xlarge. Binaries compiled using following command lines:
Running vcvarsall.bat seems to not affect result of build and how resulting binaries behave Analysis:
in other words, no obvious reason why one would be so consistently slower than another Evergreen build:
Unanswered questions:
Recommendation:
|