[SERVER-47715] Remove mongos dependency on rw_concern_d library Created: 23/Apr/20 Updated: 06/Dec/22 Resolved: 26/Mar/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.4.0-rc2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | James Heppenstall | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||
| Participants: | |||||||||
| Description |
|
rw_concern_d is a mongod-specific library but appears to wind up as a dependency in libraries, such as service_entry_point_common, sharding_catalog_manager, and transaction_coordinator, which are not mongod-specific. As a result, statically compiling the mongos leads to all symbols in rw_concern_d being included in the binary. This is incorrect because, among other things, it links the JournalFlusher into the mongos and has caused problems when adding new code (TTLMonitor with ServerStatusMetricField instances) to the storage control API (the storage_control library is a dependency of rw_concern_d). We should aim to remove the mongos dependency on rw_concern_d. |
| Comments |
| Comment by Ratika Gandhi [ 26/Mar/21 ] |
|
Closing the ticket because it is not causing any major issues as far as we can tell. |
| Comment by Daniel Gottlieb (Inactive) [ 02/May/20 ] |
|
I did some research to verify that our observation of rw_concern_d being included in mongos did not corollate with an increase in mongos size. I didn't directly search for when rw_concern_d was included; I was generally concerned in learning if there was an unrealized increase in mongos binary size between 4.2 and (a candidate) 4.4. I observed that the mongos binary did increase from ~35MB to ~49MB. This was due to a single commit: mongos now includes the mozjs library. I'm double-checking with the author that this was intentional (which is likely). I'm moving this ticket to the backlog as there's no urgent need to address the rw_concern_d library included in mongos. |
| Comment by Dianna Hohensee (Inactive) [ 23/Apr/20 ] |
|
Maybe just for our purposes we could: separate journal_flusher library, included in storage_control and write_concern.cpp. Then we don't drag all of storage_control, including ttl monitor, into write_concern.cpp, which is included in mongos. Right now we have write_concern.cpp calling StorageControls::waitForJournalFlush, and we could just do JournalFlusher::get(serviceCtx)->waitForJournalFlush. I haven't verified that this would work. |