[SERVER-4736] less aggressive resets on remote staleconfigexception Created: 20/Jan/12  Updated: 11/Jul/16  Resolved: 06/Mar/14

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 2.5.4

Type: Improvement Priority: Major - P3
Reporter: Greg Studer Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

When recving a StaleConfigException from a remote server, a less aggressive process would be as follows :

1) If version required in exception matches the current cached version, we just need to reset the version on the connection itself. This requires passing back the desired version as a field.

2) If version required != current version, we should reload the chunk manager if required. Reloads should be explicitly rate-limited by a mutex, and on acquiring the mutex we should check to see if a newer version of the chunk manager now exists (or if the state has changed, i.e. the collection is now removed).

3) Full reloads of the database should also be explicitly rate-limited, to avoid forcing all connections to re-establish their state.

Potentially also reworking the sequence number logic to store versions-per-ns-per-shard-per-connection would also significantly reduce unnecessary round-trips to the shards.


Generated at Thu Feb 08 03:06:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.