[SERVER-28448] Shard find commands get unnecessarily serialized by the ShardingState refresh rate limiting Created: 23/Mar/17  Updated: 06/Dec/17  Resolved: 06/Apr/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.12
Fix Version/s: 3.2.13

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kaloian Manassiev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-04-17
Participants:
Case:

 Description   

The find command implementation in 3.2 indiscriminately calls ShardingState::refreshMetadataIfNeeded even if no migrations or shard version mismatch has been found for the collection being queried.

This is bad, because the refreshMetadataIfNeeded call is internally rate limited to at most 3 concurrent callers in order to not overwhelm the config server if refresh "is needed". However the rate limiting is done at the wrong place - where the in-memory check is done instead when the refresh from the config server is actually.

This check should only be done if stale version has been hit and not on all occasions.



 Comments   
Comment by Githook User [ 06/Apr/17 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-28447/SERVER-28448 Only refresh metadata or wait for critical section on StaleConfigException
Branch: v3.2
https://github.com/mongodb/mongo/commit/5a5098ea760396adbb9b096bed6c30357ab3cacd

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