[SERVER-32630] Minimize reads of the featureCompatibilityVersion parameter that occur prior to the featureCompatibilityVersion document being read/created Created: 10/Jan/18  Updated: 30/Oct/23  Resolved: 09/Mar/18

Status: Closed
Project: Core Server
Component/s: Upgrade/Downgrade
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Task Priority: Major - P3
Reporter: Maria van Keulen Assignee: Maria van Keulen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-11443 Docs for SERVER-32630: Minimize reads... Closed
Related
related to SERVER-48044 FCV::isVersion should invariant if FC... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-03-12
Participants:

 Description   

Presently, there are places in the server code that read the featureCompatibilityVersion parameter before it is explicitly initialized with a meaningful value either from reading the featureCompatibilityVersion document or creating a new featureCompatibilityVersion document on clean startup. These reads should be minimized if not eliminated. A proposal to minimize these reads follows:

  • Continue to default the featureCompatibilityVersion parameter to the "unset" value.
  • Assert that the featureCompatibilityVersion parameter is not "unset" in the default getter function (getVersion).
  • For existing reads of the featureCompatibilityVersion parameter, find all reads that occur prior to the document being read. Most if not all of these should be 3.4 to 3.6 specific and thus get removed. If any such reads remain after removal of 3.4 to 3.6-specific behavior, and they must be kept, handle them with a special unsafe getter function that treats the "unset" value as last-stable.


 Comments   
Comment by Githook User [ 25/Jan/19 ]

Author:

{'username': 'adamlsd', 'email': 'adam.martin@10gen.com', 'name': 'ADAM David Alan Martin'}

Message: SERVER-39000 Fix Unittest Framework initialization.

Some tests in `dbtest` do not use the `mongo::unittest::Test` class
as a basis for their implementation and thus need some way to benefit
from global DB Environment initialization functions. Specifically
the changes in SERVER-32630 required `serverCompatibilityVersion`
to be set sensibly. Some tests in `dbtest` were not correctly
getting this benefit; instead only incidentally getting a correct
setting by accident, as the results of an unintended residue of
an earlier operation. This can lead to inconsistentcies in which
tests pass, as link order changes – the tests are registered using
static initialization, whose instability of order can cause
mysterious failures in `dbtest`.
Branch: master
https://github.com/mongodb/mongo/commit/677a65ba43fecf7cf20b7a2c34b5ec2bed413edd

Comment by Githook User [ 16/Jan/19 ]

Author:

{'username': 'adamlsd', 'email': 'adam.martin@10gen.com', 'name': 'ADAM David Alan Martin'}

Message: SERVER-39000 Fix Unittest Framework initialization.

Some tests in `dbtest` do not use the `mongo::unittest::Test` class
as a basis for their implementation and thus need some way to benefit
from global DB Environment initialization functions. Specifically
the changes in SERVER-32630 required `serverCompatibilityVersion`
to be set sensibly. Some tests in `dbtest` were not correctly
getting this benefit; instead only incidentally getting a correct
setting by accident, as the results of an unintended residue of
an earlier operation. This can lead to inconsistentcies in which
tests pass, as link order changes – the tests are registered using
static initialization, whose instability of order can cause
mysterious failures in `dbtest`.
Branch: SERVER-29286
https://github.com/mongodb/mongo/commit/9aa2832dae9477784d4a347b3f0c9de3a357e863

Comment by Githook User [ 09/Mar/18 ]

Author:

{'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}

Message: SERVER-32630 Ensure the fCV parameter is initialized before reading
Branch: master
https://github.com/mongodb/mongo/commit/a4d29b292f1bc42ae8133b0a0984c2b012c43528

Comment by Maria van Keulen [ 27/Feb/18 ]

To ensure arbiters don't trip the "unset" assertion, they should initialize their fCV parameter at the point in startup when they find out they are arbiters. To avoid bugs such as SERVER-32639 in the future, arbiters should initialize the fCV to whatever the "latest" fCV is, in this case, 4.0.

Comment by Tess Avitabile (Inactive) [ 13/Feb/18 ]

Please recall while doing this work that arbiters will never read the FCV document.

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