[SERVER-53815] NamespaceMetadataChangeNotificationsTest, and other sharding unit test fixtures, call ServiceContext::setTickSource() after the JournalFlusher, which uses the TickSource, is started in ServiceContextMongoDTest Created: 14/Jan/21  Updated: 06/Dec/22  Resolved: 19/Jan/21

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-53875 Stop the JournalFlusher thread from r... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 119

 Description   

The JournalFlusher initiated by ServiceContextMongoDTest uses the TickSource set on the ServiceContext. NamespaceMetadataChangeNotificationsTest sets a new TickSource on the ServiceContext, which deletes the original TickSource without any concurrency control. Therefore, we must adjust the ServiceContext's TickSource before the JournalFlusher is started up.

We could push NamespaceMetadataChangeNotificationsTest's ServiceContext::setTickSource() call into the ServiceContextMongoDTest base class before the JournalFlusher is started via StorageControl::startStorageControls. However, there are other unit tests, not currently failing, which also call ServiceContext::setTickSource(). Maybe we need some lower level test fixture for sharding setting TickSource the like??



 Comments   
Comment by Dianna Hohensee (Inactive) [ 19/Jan/21 ]

Filed SERVER-53875 to provide a fix for unit tests generically rather than only this one specifically.

Generated at Thu Feb 08 05:31:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.