[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:
Related
related to SERVER-47386 Complete TODO listed in SERVER-46075 Closed
is related to SERVER-45741 Migration coordination stepup task sh... Closed
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 SERVER-45577.



 Comments   
Comment by Githook User [ 20/Feb/20 ]

Author:

{'username': 'saltzm', 'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com'}

Message: SERVER-46075 Make new executor for submitting range deletion tasks
Branch: master
https://github.com/mongodb/mongo/commit/a8fdddf98dd47b65b05ce28d41214ba87446f626

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.

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