[SERVER-36736] Avoid doing work in Client lock when destroying OperationContextSession Created: 17/Aug/18 Updated: 29/Oct/23 Resolved: 28/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Matthew Russotto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Repl 2018-08-27, Repl 2018-09-10 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 11 | ||||||||||||
| Description |
|
When OperationContextSession is destroyed, it destroys the operationSessionDecoration on the OperationContext under the Client lock. Destroying the operationContextDecoration (which is a ScopedCheckedOutSession) takes the SessionCatalog mutex. Other code takes the SessionCatalog mutex and then the Client lock (implicitly in waitForConditionOrInterruptUntil) so this causes deadlocks. Instead we should take the Client lock, move the ScopedCheckedOutSession from the operationSessionDecoration to a local variable, then release the Client lock and destroy the ScopedCheckedOutSession without the lock. |
| Comments |
| Comment by Githook User [ 28/Aug/18 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@10gen.com', 'username': 'mtrussotto'}Message: |