[SERVER-33577] Remove UninterruptibleLockGuards in sharding code to allow interruptible lock acquisition Created: 01/Mar/18 Updated: 27/Oct/23 Resolved: 15/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.7.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||||||||||||||
| Sprint: | Sharding 2019-02-11 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
| Comments |
| Comment by Kaloian Manassiev [ 15/Mar/19 ] |
|
As part of the dependent tickets we have removed the UninterruptibleLockGuard(s) necessary for the replication stepdown project. The remaining places, which Blake has linked are about cleaning up the internal sharding data structures and removing them without some redesign is difficult. Given that the prepare project is unblocked now, I am going to close this ticket as Works as Designed. |
| Comment by Blake Oler [ 21/Feb/19 ] |
|
We have removed some of these since. We have gone from 16 uses to 11 – in that process, we removed all uses from the MigrationDestinationManager and ReplsetDistLockManager. I linked some relevant tickets. CC greg.mckeon |
| Comment by Kaloian Manassiev [ 02/Mar/18 ] |
|
The migration source manager is not 100% exception-safe, especially during the migration critical section. It would require some redesign to be able to remove the UninterruptibleLockGuards, so I am putting this on 3.7 Desired, to be done if time permits. |