[SERVER-66909] Investigate how to stop using ShardLocal Created: 31/May/22  Updated: 06/Jun/22  Resolved: 06/Jun/22

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

Type: Improvement Priority: Major - P3
Reporter: Andrew Witten (Inactive) Assignee: Andrew Witten (Inactive)
Resolution: Duplicate Votes: 0
Labels: sharding-nyc-subteam2, sharding-nyc-subteam2-catalog-poc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-66711 Get rid of ShardLocal Closed
Participants:

 Description   

The Shard interface is difficult to use, and leads to bugs.  There are two implementations of the Shard interface: ShardLocal and ShardRemote.  However, they are not interchangeable.  Throughout the ShardLocal class, many functions hit a MONGO_UNREACHABLE, despite the fact that we usually call these functions through the base class Shard.

Furthermore, the Shard interface supports a generic `runCommand` function that at first glance seems to support arbitrary server commands. However, this is not the case for multiple reasons.  First, DBDirectClient (which ShardLocal wraps) only supports CRUD operations.  Second, DBDirectClient does not support session information in commands.

We should use ShardRemote instead of ShardLocal when the CSRS talks to itself.  

There may exist times when the CSRS absolutely must bypass the networking stack.  In those cases we should use a thin wrapper on DBDirectClient that enforces the limitations of DBDirectClient in its API and does not derive Shard (ShardLocal does not satisfy these conditions).

 

These issues have greatly complicated PM-2290.


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