[SERVER-53131] TenantMigrationRecipientService::Instance::interrupt() should be able to interrupt steps waiting for an opTime to be majority replicated. Created: 30/Nov/20 Updated: 06/Dec/22 Resolved: 01/Apr/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Suganthi Mani | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | pm-1791_non-cloud-blocking, pm-1791_optimizations | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
(This is just an optimization ticket) Currently there are many places in instance task where it wait for an opTime to be majority replicated(like here). These waits are interrupted only during node step down but if TenantMigrationRecipientService::Instance::interrupt() gets called due to some oplog fetcher error, recipient shutdown or on receive recipientForgetMigration cmd, the opTime wait steps aren't interrupted. |
| Comments |
| Comment by Lingzhi Deng [ 01/Apr/21 ] |
|
The WaitForMajorityService should already be interrupting all waiters on shutdown. I think the optime majority waits are not interrupted if the interrupt() is called by oplog fetcher errors or the recipientForgetMigration commands. So I think it is probably not worth the effort optimizing this one. And I think ideally we should leverage the CancelationToken more for interruptibility in general in both the donor and the recipient service. And we have SERVER-53389. I am closing this as "Won't fix" for now. |