[SERVER-68874] Consider making waitAfterPinningCursorBeforeGetMoreBatch only hang instead of also fiddling with locks (while-loop taking and releasing locks) Created: 16/Aug/22  Updated: 05/Dec/22  Resolved: 06/Sep/22

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Query Execution
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-68868 Remove all instances of Uninterruptib... Blocked
Duplicate
duplicates SERVER-69059 Create an InterruptibleLockGuard to p... Closed
Related
is related to SERVER-27534 All writing operations must fail if t... Closed
is related to SERVER-21997 kill_cursors.js deadlocks Closed
Assigned Teams:
Query Execution
Participants:

 Description   

I think the looping of taking and releasing locks is outdated now that MMAP is gone. The failpoint name suggests it is only used to hang an active getMore command. The failpoint and lock manipulation were added in SERVER-21997 because of a MMAP deadlock: MMAP is gone now. The looping today is occurring via this lambda passed into CurOpFailpointHelpers::waitWhileFailPointEnabled

My goal in filing this ticket is to get rid of the UninterruptibleLockGuard used here for a failpoint. UninterruptibleLockGuard should be used when there is no alternative: it's a hack that breaks rules and we'd like to remove it entirely. I didn't figure out why SERVER-27534 added the use to the failpoint case.

If the loop cannot be removed, I wonder if the UninterruptibleLockGuard use can be.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 06/Sep/22 ]

Yes, it was just fixed by SERVER-69059. Thanks for catching that! I forgot to update this ticket.

Comment by Brenda Rodriguez [ 06/Sep/22 ]

dianna.hohensee@mongodb.com could you verify if this work was done in a different ticket? Thanks!

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