[SERVER-46075] Use asynchronous version of forceShardFilteringMetadataRefresh when submitting range deletion task Created: 11/Feb/20 Updated: 29/Oct/23 Resolved: 20/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Matthew Saltz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2020-03-09 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The task to submit range deletions is scheduled on the fixed sharding executor but may force a filtering metadata refresh, which currently is synchronous. Instead of blocking a fixed executor thread, there should be a way to perform this refresh asynchronously. This was spun out from |
| Comments |
| Comment by Githook User [ 20/Feb/20 ] |
|
Author: {'username': 'saltzm', 'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 14/Feb/20 ] |
|
After more discussion, we should just make the separate executor, since we cannot predict how many threads a host may have, e.g. if it is running in a VM. |
| Comment by Esha Maharishi (Inactive) [ 14/Feb/20 ] |
|
Garaudy to investigate how many sharded collections our largest customers have. If > 10k, we should make a separate executor for this with a fixed size so that setFCV upgrade cannot crash shard nodes. |