[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: |
|
||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
||||||||||||||||||||||||||||||
| 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 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 |
| 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. |