[SERVER-23669] Make _opTime required (not boost::optional) in ConfigServerMetadata Created: 12/Apr/16  Updated: 07/Jun/16  Resolved: 07/Jun/16

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Leon Zaruvinsky
Resolution: Done Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-24458 Assert that ConfigServerMetadata is a... Closed
Sprint: Sharding 16 (06/24/16)
Participants:

 Description   

v3.2 non-config shards and later always return ConfigServerMetadata in command responses, so the ConfigServerMetadata::opTime field should not be boost::optional anymore.

1) Remove the opTime.is_initialized check from ShardingEgressMetadataHook::_advanceConfigOpTimeFromShard():

auto opTime = configMetadata.getOpTime();
if (opTime.is_initialized()) {
    grid.advanceConfigOpTime(opTime.get());
}

2) Make _opTime non-optional in config_server_metadata.h:

    boost::optional<repl::OpTime> getOpTime() const {
        return _opTime;
    }
 
private:
    boost::optional<repl::OpTime> _opTime;



 Comments   
Comment by Spencer Brody (Inactive) [ 07/Jun/16 ]

There are still times when ConfigServerMetadata gets used when no config server optime is actually included, namely on mongod side when mongod is parsing requests from mongos. Mongods always include the ConfigServerMetadata on their responses, but mongos doesn't always include it on its requests. So we should do SERVER-24458 instead of this.

Comment by Esha Maharishi (Inactive) [ 13/Apr/16 ]

Never mind, it should be "v3.2 shards and later." Config servers never returned ConfigServerMetadata; the opTime field was optional because of mixed-version 3.0 and 3.2 shards doing migrations.

Comment by Esha Maharishi (Inactive) [ 13/Apr/16 ]

I believe v3.4 shards and later is correct, since in v3.2, SCCC config servers (which did not send ConfigServerMetadata) were still allowed. Only in 3.4 do all mongod nodes always send ConfigServerMetadata in response to commands.

Comment by Andy Schwerin [ 13/Apr/16 ]

esha.maharishi, should the description actually say "v3.2 shards and later..."?

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