[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:
Related
related to SERVER-36841 TTL thread can (very rarely) race wit... Closed
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_commonsharding_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.

Generated at Thu Feb 08 05:15:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.