[SERVER-32145] Avoid dropping lock before cleaning up DocumentSourceCursor's PlanExecutor Created: 01/Dec/17  Updated: 30/Oct/23  Resolved: 07/Dec/17

Status: Closed
Project: Core Server
Component/s: Aggregation Framework, Performance
Affects Version/s: None
Fix Version/s: 3.6.2, 3.7.1

Type: Improvement Priority: Major - P3
Reporter: Charlie Swanson Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Query 2017-12-18
Participants:
Linked BF Score: 0

 Description   

In order to dispose of a PlanExecutor, we need to acquire the collection lock to avoid races upon deregistering the PlanExecutor from the CursorManager. However, in the case where the PlanExecutor has been exhausted or the limit has been reached (this case) we end up releasing the lock directly before re-acquiring it to dispose of the PlanExecutor. We should simply dispose of the PlanExecutor while we still hold the lock.



 Comments   
Comment by Githook User [ 02/Jan/18 ]

Author:

{'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}

Message: SERVER-32145 Avoid dropping lock before disposing of PlanExecutor
Branch: v3.6
https://github.com/mongodb/mongo/commit/81706786679050a62704bd4480642b3d1bb46ee9

Comment by Githook User [ 07/Dec/17 ]

Author:

{'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}

Message: SERVER-32145 Avoid dropping lock before disposing of PlanExecutor
Branch: master
https://github.com/mongodb/mongo/commit/8d2a7030e31ef857889d22f7246b77f7f13194cd

Comment by Charlie Swanson [ 01/Dec/17 ]

Yep! summarized/linked in the code review.

Comment by David Storch [ 01/Dec/17 ]

Agree, as long as experiments show that there is a real performance benefit associated with this change. Do you have any numbers yet?

Comment by Charlie Swanson [ 01/Dec/17 ]

david.storch I dropped this into the current sprint, let me know if you disagree.

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