[SERVER-76516] Fix Concurrent Access of Clock in ReshardingRecipientServiceTest in 5.0 Branch Created: 25/Apr/23 Updated: 29/Oct/23 Resolved: 27/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 5.0.17 |
| Fix Version/s: | 5.0.18 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Brett Nawrocki | Assignee: | Brett Nawrocki |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-nyc-subteam1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Sharding NYC 2023-05-01 | ||||
| Participants: | |||||
| Linked BF Score: | 29 | ||||
| Description |
|
RestoreMetricsAfterStepUp relies on the global ServiceContext's clock source to really be a ClockSourceMock. In the 6.0 branch, this is achieved by using the useMockClock option on the test frameworks. However, in 5.0, this option is not available, and so the ReshardingRecipientServiceTest sets this up after calling repl::PrimaryOnlyServiceMongoDTest::setUp(). PrimaryOnlyServiceMongoDTest::setUp() also will set up PrimaryOnlyService for the test, which will begin accessing the clock source from a separate thread. It's therefore possible that the PrimaryOnlyService accesses the clock source while the ReshardingRecipientServiceTest is setting the clock source, causing TSAN to complain. |
| Comments |
| Comment by Githook User [ 27/Apr/23 ] |
|
Author: {'name': 'Brett Nawrocki', 'email': 'brett.nawrocki@mongodb.com', 'username': 'brettnawrocki'}Message: |