[SERVER-23345] RAII semantics for ReplicaSetMonitor Created: 25/Mar/16  Updated: 28/Sep/16  Resolved: 01/Aug/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.3.11

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Misha Tyulenev
Resolution: Done Votes: 0
Labels: PM550
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-8924 RAII semantics for ReplicaSetMonitor Closed
Related
related to SERVER-23192 mongos and shards will become unusabl... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 14 (05/13/16), Sharding 15 (06/03/16), Sharding 16 (06/24/16), Sharding 18 (08/05/16)
Participants:
Linked BF Score: 0

 Description   

Delegate the cleanup of resources used by ReplicaSetMonitor the do its d-tor. Currently its done in ReplicaSetMonitor::remove() .

a) Change ReplicaSetMonitorManager _monitors type to StringMap<std::weak_ptr<RepliceSetMonitor>>
so the map does not own monitors and hence every object will call a d-tor as soon as its refcount is 0

b) ReplicaSetMonitor::~ReplicaSetMonitor will now be called when it goes out of scope and hence it should erase itself from the _monitors map.

c) ReplicaSetMonitorManager::getMonitor should
lock() a weak_ptr to existing monitor to convert it to shared_ptr() before returning it. It should invariant that lock() works i.e. the map can not have a dangling weak_ptr.

d) disallow calling ReplicaSetMonitor::remove() - make its private or delete if not needed

e) Optionally in the case there is need to get a shared_ptr from ReplicaSetMonitor object: derive ReplicaSetMonitor from enable_shared_from_this and use shared_from_this() call to get shared_ptr.



 Comments   
Comment by Misha Tyulenev [ 01/Aug/16 ]

The required changes are documented in SERVER-23192

Comment by Misha Tyulenev [ 01/Aug/16 ]

SERVER-23192 resolved all but d) RSM::remove and other RSM methods should not be used directly as the shard ownership of RSM (thru the targeter) supposed to take care of the RSM life cycle via RAII and this commit will bring us closer. The problem is the dbclient_rs that owns RSM (directly) so the RSM owned by a removed shard may not be recreated on the ShardRegistry reload.
Therefore this functionality will be solved in the context of refactoring dbclient_rs.

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