[SERVER-33765] Log (and parse) the shard identifier given to ShardRegistry::getShard(NoReload) Created: 08/Mar/18  Updated: 06/Dec/22  Resolved: 16/Mar/18

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

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-33017 Add metadata hook to update lastCommi... Closed
Assigned Teams:
Sharding
Participants:

 Description   

ShardRegistry::getShard(NoReload) accepts a ShardId and returns the associated Shard object. Confusingly, the _lookup map it uses actually contains HostAndPort and ConnectionStrings as keys in addition to ShardIds, so getShard(NoReload) can implicitly work with either of those types, since they're all essentially strings.

The ShardingEgressMetadataHook and the newly added CommittedOpTimeMetadataHook both use this behavior because the replySource given to each can be either a HostAndPort or a replica set ConnectionString, depending on which type of network connection was used (ASIO vs. DBClientReplicaSet).

To make debugging simpler, this value should be logged (and possibly parsed). Alternatively, we could change the two hooks that rely on this behavior to parse the replySource first and call an appropriate ShardRegistry method instead.



 Comments   
Comment by Kaloian Manassiev [ 16/Mar/18 ]

Closing this as Won't Fix, because it will naturally go away once we get rid of usages of DBClient in sharding.

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