Details
Description
Filed to investigate why, and if its expected update the docs to warn users that follow up reads will not be causally consistent with the findAndModify unless it uses w:majority.
the issue logs:
https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_causally_consistent_jscore_passthrough_auth_WT_c7aa40633696a49fea2e75750b30a8339117d072_17_06_16_16_23_00
After the root cause is determined here is the proposal to address the issue:
1. Add OperationContext argument to interface EgressMetadataHook::readReplyMetadata
virtual Status readReplyMetadata(OperationContext* opCtx, StringData replySource, const BSONObj& metadataObj) = 0;
|
2. In ShardingConnectionHook::onCreate add the opCtx for replyMetadataReader:
if (_shardedConnections) {
|
conn->setReplyMetadataReader([this](OperationContext* opCtx, const BSONObj& metadataObj, StringData target) {
|
return _egressHook->readReplyMetadata(opCtx, target, metadataObj);
|
});
|
}
|
3. in DBClientWithCommands::runCommandWithTarget pass the operationContext to the _metadataReader call
Reading OperationTime
4. add OperationTimeHook class
Status OperationTimeHook::readReplyMetadata(OperationContext* opCtx, StringData replySource,
|
const BSONObj& metadataObj) {
|
std::shared_ptr<OperationTimeTracker> timeTracker = OperationTimeTracker::get(opCtx);
|
|
|
auto operationTime =metadataObj[kOperationTimeField];
|
if (!operationTime.eoo()) {
|
invariant(operationTime.type() == BSONType::bsonTimestamp);
|
timeTracker->updateOperationTime(LogicalTime(operationTime.timestamp()));
|
}
|
|
|
}
|
5. install OperationTimeHook to the hook list in runMongosServer
unshardedHookList->addHook(stdx::make_unique<rpc::OperationTimeHook>());
|
shardedHookList->addHook(stdx::make_unique<rpc::OperationTimeHook>());
|
Attachments
Issue Links
- is duplicated by
-
SERVER-29455 Mongos egress operations over DBClient must update OperationTimeTracker
-
- Closed
-
- is related to
-
SERVER-29629 Add causally consistent passthrough with auth
-
- Closed
-