[SERVER-48153] Chunk migration can still be running even after the moveChunk command fails with maxTimeMS timeout Created: 12/May/20  Updated: 26/Oct/23

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

Type: Improvement Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea, sharding-common-backlog, shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-72329 Complete TODO listed in SERVER-30179 Blocked
Duplicate
is duplicated by SERVER-30179 moveChunk doesn't obey maxTimeMS cons... Closed
Related
is related to SERVER-30179 moveChunk doesn't obey maxTimeMS cons... Closed
is related to SERVER-47003 MaxTimeMSExceeded on _configsvrMoveCh... Closed
is related to SERVER-48699 MaxTimeMS may expire in range_deleter... Closed
Assigned Teams:
Catalog and Routing
Participants:
Story Points: 3

 Description   

This means that running a new migration immediately after a previous one failed with timeout can fail because there's a conflicting chunk migration in progress.



 Comments   
Comment by Connie Chen [ 21/Dec/22 ]

After scoring this ticket, we think it is unlikely that we will do this in the near future, but we'll keep it in our QWs bucket

Comment by Esha Maharishi (Inactive) [ 13/May/20 ]

Changing from "Bug" to "Improvement" because this works as designed, though it would be nice if either:

1) The later migration could block behind the first one, or

2) The first migration could be aborted if the client's maxtTimeMS expired on the donor and the donor had not sent commit to the config server yet.

 

This is also related to the idea of long-running commands returning quickly to the client and their progress being poll-able.

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