[SERVER-46869] Make the OplogCapMaintainerThread interruptible and handle its life cycle Created: 13/Mar/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-04-20 | ||||||||
| Participants: | |||||||||
| Description |
|
The OplogCapMaintainerThread currently is created without ownership and never shutdown. I want to make it interruptible and owned, pushing it into the new StorageControls infrastructure created in |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 17/Apr/20 ] |
|
Going to do this later: more pressing work to do. Current state is that the logic hangs. My latest idea is to make use the existing start/stop logic for OplogStones, and not add the interrupt via opCtx logic that appears hung. Need to backtrack, basically, because the first version worked and then the changes I made are really not working. |