Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.7.0
Affects Version/s: None
Component/s: Sharding
Labels:
- PM-1645-Milestone-1

Backwards Compatibility:
Fully Compatible
Sprint:
Sharding 2020-05-18, Sharding 2020-06-01
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

Optimize ScopedShardVersionCriticalSection class with respect to multi-thread initialization. In particular in the case where a lot of threads try to concurrently instantiate this object.

The idea is to avoid entering in the critical session if it is not strictly needed.

Modify onShardVersionMismatch in order to:

Wait on an ongoing shard version refresh or trigger it with a forceShardFilteringMetadataRefresh call

Update forceShardFilteringMetadataRefresh:

Remove forceRefreshFromThisThread flag
Remove unused hasAdditionalCatalogCacheForFiltering part

causes

SERVER-48487 Use DBLock instead of AutoGetDB in onShardVersionMismatch

Closed

depends on

SERVER-47974 Introduce ScopedShardVersionCriticalSection class

Closed

is depended on by

SERVER-45983 Perform the shardVersion recovery and refresh on a separate thread from that of the user request

Closed

SERVER-47982 Change the shard version update procedure of the migration source manager

Closed

SERVER-47985 Implement recovery of a shard's `shardVersion` before it is allowed to perform version checking

Closed

is duplicated by

SERVER-48180 Make onShardVersionMismatch use ScopedShardVersionCriticalSection

Closed

(1 is duplicated by)

Assignee:: Pierlauro Sciarelli
Reporter:: Tommaso Tocci
Participants:: Githook User, Pierlauro Sciarelli, Tommaso Tocci
Votes:: 0 Vote for this issue
Watchers:: 2 Start watching this issue

Created:: May 06 2020 02:15:42 PM UTC
Updated:: Oct 29 2023 10:08:38 PM UTC
Resolved:: May 26 2020 07:23:03 PM UTC

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates