[SERVER-44791] Abort index builds by interrupting the OperationContext of the builder thread Created: 22/Nov/19  Updated: 10/Apr/20  Resolved: 10/Apr/20

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

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-44722 3 way deadlock can happen between hyb... Closed
Duplicate
duplicates SERVER-46560 Make Abort index build logic determin... Closed
is duplicated by SERVER-46012 Aborting index builders through the I... Closed
Related
related to SERVER-46595 createIndexes command fails to abort ... Closed
related to SERVER-46012 Aborting index builders through the I... Closed
is related to SERVER-39976 Two-phase index builds on primaries s... Closed
Sprint: Execution Team 2020-04-06, Execution Team 2020-04-20
Participants:
Linked BF Score: 5

 Description   

The current mechanism for aborting index builds through the IndexBuildsCoordinator is to set a flag on the MultiIndexBlock.

During the index build process we check if this flag has been set a few times. For example, at the begining of each drain phases, of which there are only 3 calls.

This makes it difficult and unreliable to abort index builds because the window between aborting an index build and it actually tearing down is potentially very wide for large indexes.

In part because of the deadlock described by SERVER-44722, it would be better to actually interrupt the operation context of the index builder thread. Lock acquisitions or explicit calls to checkForInterrupt() should throw and immediately abort the index build.



 Comments   
Comment by Louis Williams [ 10/Apr/20 ]

This work was completed by SERVER-46560.

Comment by Louis Williams [ 02/Mar/20 ]

I'm not sure this is going to be possible now that index build threads ignore interrupts.

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