[SERVER-31056] Remove all usages of the default constructor of ScopedCollectionMetadata outside of MetadataManager Created: 12/Sep/17 Updated: 30/Oct/23 Resolved: 06/Dec/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.5.13 |
| Fix Version/s: | 3.6.1, 3.7.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||
| Sprint: | Sharding 2017-12-04, Sharding 2017-12-18 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The ScopedCollectionMetadata object is supposed to only be created by the MetadataManager since only it knows definitively what the current metadata for the collection is. Currently there are call sites which create ScopedCollectionMetadata using the default constructor, which makes it difficult to ensure correctness in one place. Because of this we should remove all usages of the default constructor outside of MetadataManager. |
| Comments |
| Comment by Githook User [ 08/Dec/17 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: Contains the combined backport of multiple commits listed below.
No functional changes, only cleanup to improve readability.
(cherry picked from commit 88fa04b3791d1e53444601432677bb0cf86dc293)
It shouldn't contain state internal to the metadata manager. (cherry picked from commit b732abe6b1295740c3a5799c5903f84cd1857347)
(cherry picked from commit 95e95613412c33b52bb8a514751550c2447526d4)
With this commit, only the MetadataManager is allowed to instantiate (cherry picked from commit 762765c80b005375c3c3b893772c7284271598ea)
(cherry picked from commit d5be73dbe4d28211994746dc1f5b47fb840ccdbd)
The StaleConfig error code is interpreted in a special way and it (cherry picked from commit 4fcaef90b1ca91b4806bace87da568565d5633c9) |
| Comment by Kaloian Manassiev [ 06/Dec/17 ] |
|
Due to the extent of the preparation changes which were necessary in order to fix this bug, I am retitling it to mean "remove all usages of the default constructor of ScopedCollectionMetadata" and moving the final fix to differentiate between unsharded and "metadata not known" to |
| Comment by Githook User [ 06/Dec/17 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: The StaleConfig error code is interpreted in a special way and it |
| Comment by Githook User [ 06/Dec/17 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: |
| Comment by Githook User [ 05/Dec/17 ] |
|
Author: {'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}Message: With this commit, only the MetadataManager is allowed to instantiate |
| Comment by Githook User [ 04/Dec/17 ] |
|
Author: {'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}Message: |
| Comment by Githook User [ 29/Nov/17 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: It shouldn't contain state internal to the metadata manager. |
| Comment by Githook User [ 29/Nov/17 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: No functional changes, only cleanup to improve readability.
|
| Comment by Spencer Brody (Inactive) [ 22/Nov/17 ] |
|
If this is easy to do, then it'd be nice to do sooner and backport to 3.6 so changestreams can benefit from it in 3.6, rather than waiting and doing it as part of the larger collection lifecycle work. |
| Comment by Kaloian Manassiev [ 22/Nov/17 ] |
|
This is not difficult to do. We can just make the MetadataManager have a state, which indicates "I don't know what's the metadata", which would always fail the shard version check. |
| Comment by Andy Schwerin [ 22/Nov/17 ] |
|
I think we should consider this along with driving "shard collection" on the shard that owns the unsharded collection in order to make the routing table maintenance protocols more robust. Moving this back to "Needs Triage" to see if this could be done as part of collection lifecycle improvements or as a one-off during 3.7 development, perhaps with back port to 3.6. |
| Comment by Spencer Brody (Inactive) [ 22/Nov/17 ] |
|
Note that linked ticket |
| Comment by Spencer Brody (Inactive) [ 22/Nov/17 ] |
|
This issue also affects changeStreams. |
| Comment by Dianna Hohensee (Inactive) [ 14/Nov/17 ] |
|
This can further occur on a secondary via the oplog when metadata changes reach it. Both entering the critical section and finishing a metadata refresh will persist changes that the secondary will notice in its oplog and prompt clearing of the metadata, leaving it in the same susceptible position noted in the ticket description. This can happen as of |