[SERVER-39225] Update kill_rooted_or.js / IndexBuildsCoordinator to gracefully handle index build already in-progress errors Created: 28/Jan/19  Updated: 27/Oct/23  Resolved: 22/Feb/19

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-39369 Filter index builds requests in the c... Closed
is depended on by SERVER-39454 Move createIndexes command fully onto... Closed
Related
related to SERVER-41554 Remove applyOps support for createInd... Closed
related to SERVER-50395 Investigate whether can try to resume... Closed
Sprint: Storage NYC 2019-02-11, Storage NYC 2019-02-25
Participants:
Story Points: 3

 Description   

"The Coordinator registers each index spec by name that comes in, before the indexes are set up in the index catalog as in-progress. Then subsequent requests with the same index names hit an error in the Coordinator. Without the Coordinator, spec requests are normally automatically filtered out if they're already found to be built or building via the index catalog.

The concurrency test has 10 threads, potentially all running the same createIndexes requests at the same time, so "There's already an index with name..." errors make sense – previously they'd get filtered out and the redundant commands return OK.

Perhaps a new error code IndexBuildAlreadyInProgressForName to fix tests, and we can consider the final behavior changes later, and easily identify the changes by error code if we want to undo them. This is related to our problem regarding spec checking being scattered all over the place at different levels of the code."



 Comments   
Comment by Dianna Hohensee (Inactive) [ 22/Feb/19 ]

This should be resolved with the commit of SERVER-39369.

Generated at Thu Feb 08 04:51:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.