-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Service Arch
-
Service Arch 2023-10-16, Service Arch 2023-10-30
When a client of the embedded-router-server originates out-of-process (i.e. from the network), we can tag it with the service it is using (router vs. shard) based on the port it contacted us on. However, we also create several Clients in-process, which manage a logical stream of work as background jobs (i.e. a client whose job it is to kill cursors whose timeout has expired).
Each of these clients will need to be labeled with the service that they are running under in order to ensure that operations they initiate are correctly dispatched, report metrics correctly, and work with a service-aware logging system.
Some investigation may be required for edge-case clients, but as a rule of thumb:
- Process-internal Clients that currently run only in 7.0-mongos should have the router-role
- Process-internal Clients that currently run only in 7.0-mongod should have the shard-role
- Process-internal Clients that currently run in both binaries on 7.0 will require some case-by-case judgement and code review from relevant teams, but we should probably bias towards including them in the shard role, because the router services generally exist "on top of" the shard ones which are more fundamental.
- duplicates
-
SERVER-82227 Address no-argument getService calls that are present in mongod and mongos
- Backlog
-
SERVER-82225 Change no-argument calls to ServiceContext::getService to include shard cluster-role if the call is only present in mongod
- Closed
-
SERVER-82226 Change no-argument calls to ServiceContext::getService to include router cluster-role if the call is only present in mongos
- Closed
- is related to
-
SERVER-81830 Create Clients with Service, not ServiceContext
- Closed
-
SERVER-81921 Create ThreadClients with Service, not ServiceContext
- Closed
-
SERVER-82100 Make Client::initThread callers explicitly provide a Service*
- Closed