[SERVER-30179] moveChunk doesn't obey maxTimeMS consistently Created: 17/Jul/17 Updated: 21/Dec/22 Resolved: 21/Dec/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.4.6, 3.5.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | maxTimeMs, sharding-common-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
The moveChunk command crosses from mongos > config server > donor shard > recipient shard. Any maxTimeMS information gets lost after the config server. Currently it is not safe to always observe maxTimeMS or interrupt on the donor shard, because the migration critical section is not prepared to handle it and may result in fassert. This ticket is to figure out our story with moveChunk interruptability and deadline observance. Once it has been fixed, the disabled test below needs to be re-enabled. |
| Comments |
| Comment by Githook User [ 17/Jul/17 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: |