[SERVER-78976] (SA) Adapt command registry to support both router and shard commands Created: 14/Jul/23  Updated: 29/Oct/23  Resolved: 12/Sep/23

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

Type: Task Priority: Major - P3
Reporter: Paolo Polato Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-80331 (SA) Introduce "Service" objects betw... Closed
Problem/Incident
Related
related to SERVER-79352 (SA) Allow dual `MetricTree` based on... In Progress
related to SERVER-78771 Define new command repository archite... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
SERVER-79907 MONGO_REGISTER_COMMAND uniform Comman... Sub-task Closed Billy Donahue  
SERVER-80352 Remove Command self-registration Sub-task Closed Billy Donahue  
SERVER-80355 introduce Service under ServiceContex... Sub-task Closed Billy Donahue  
SERVER-80434 CommandRegistry per Service Sub-task Closed Billy Donahue  
SERVER-82682 mandatory command roles Sub-task Closed Billy Donahue  
Assigned Teams:
Service Arch
Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2023-08-07, Service Arch 2023-08-21, Service Arch 2023-09-04, Service Arch 2023-09-18
Participants:
Linked BF Score: 154

 Comments   
Comment by Billy Donahue [ 12/Sep/23 ]

subtask SERVER-80434 completed this ticket
The CommandRegistry supports router and shard Services.

Now we have to apply that support.

Comment by Billy Donahue [ 09/Aug/23 ]

I'm nearly finished converting all Command initialization to the uniform MONGO_REGISTER_COMMAND(CmdType) syntax.

This critical first step allows us to make enhancements to Command definitions by editing a central definition. It's a searchable pattern, something we don't currently have. There are currently a plethora of diverse and creative ways of making Command objects, but we can capture all of their needs with the new syntax. Anyway, just giving an update that it's going well.

The one that's giving me the most trouble is "fsync", because the "fsyncUnlock" command object calls member functions on the "fsync" command object. The "fsync" Command object manages the global fsync locks internally and that service-like code has to be separated out from the Command object that manipulates it.

This MONGO_REGISTER_COMMAND mechanism work is split off into SERVER-79907

Comment by Billy Donahue [ 03/Aug/23 ]

I think the Command object lifecycle is pretty unusual right now.

The hand raw pointers to themselves to the CommandRegistry, so the CommandRegistry can't tell if they go away. They do this in their constructor, when they're not yet completed objects, so the CommandRegistry has to be hands-off until the Command constructor is completed.

IMO the self-registration and the static duration restrictions on Command objects may need to be addressed first to enable more scalable designs for CommandRegistry.

I think it would be best if the Shard and Router registries didn't share the same set of `Command` objects, but had their own private copies held as smart pointers. I think that will probably be less confusing.

There are a few idioms for declaring Commands today and we could improve those as well.
I think the the command files should have static registration objects that tell CommandRegistries what to make, similar to Decorations.

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