[SERVER-43216] Invariant internal operations that acquire strong locks are marked killable Created: 06/Sep/19  Updated: 12/Feb/20  Resolved: 12/Feb/20

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

Type: Improvement Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Jason Chan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-43174 Designate the MigrationDestinationMan... Closed
depends on SERVER-44722 3 way deadlock can happen between hyb... Closed
depends on SERVER-42511 Remove query knob internalQueryUseAgg... Closed
Related
related to SERVER-44779 Invariant internal operations that hi... Closed
is related to SERVER-40936 add an invariant that we do not get ... Closed
is related to SERVER-41034 Invariant if we get a prepare conflic... Closed
is related to SERVER-43215 Have a better way to enforce internal... Closed
Sprint: Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18
Participants:

 Description   

Currently, internal operations rely on calling setSystemOperationKillable() to allow themselves to be killed by the RstlKillOpThread on step up/down. This design is error-prone until we do SERVER-43215.

For the time being, we should invariant internal operations that acquire strong locks are marked killable.



 Comments   
Comment by Jason Chan [ 12/Feb/20 ]

Closing this as Won't Fix. The most straightforward approach would be to add an invariant at the lock acquisition layer that internal threads that take global locks must be marked killable. However, there are certain threads that still acquire strong locks on db namespaces that we don't expect to ever hit a prepare conflict and there is currently no way to filter out these namespaces at this layer.

Comment by Jason Chan [ 21/Nov/19 ]

This ticket originally had two parts:

  1. Add an invariant when we hit a prepare conflict and check that if the conflicting thread is an internal operation, it must be marked killable.
  2. Add an invariant at lock acquisition time that if a strong lock is acquired and the conflicting thread is an internal operation, it must be marked killable. It is okay to ignore the 'local', 'admin', and 'config' name spaces since we don't expect to conflict with locks held by prepared transactions for them. 

Currently, the legacy MapReduce command grabs a CollectionLock in X mode when dropping temp collections. Since there doesn't seem like a good way to check that a collection/DB lock is acquired on a temporary collection at the lock acquisition layer, I don't think it would be worth it to make changes to the legacy MapReduce code that will be replaced soon. The Query test is in the process of switching the tests from using the legacy MapReduce to the new one where no strong locks are expected to be held. I think it would be better to hold off on (2) until SERVER-42511 is completed. 

I created SERVER-44779 to push (1) which doesn't have any dependencies on MR.

 

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