[SERVER-20556] AsyncOp cancellation is racy w.r.t. generation increment in NetworkInterfaceASIO Created: 22/Sep/15 Updated: 07/Oct/15 Resolved: 23/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Adam Midvidy | Assignee: | Adam Midvidy |
| Resolution: | Done | 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 | ||||
| Steps To Reproduce: | run sharding/find_getmore_cmd.js in a loop |
||||
| Sprint: | Platform A (10/09/15) | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
We bump the generation count in _completeOperation before resetting the state of the AsyncOp, and before removing the op from _inProgress. As a result a cancel can be scheduled after the generation is bumped, but before the op is released to the pool. Under certain (nondeterministic) timing conditions this can result in spurious cancellation if another command is immediately scheduled and gets the same AsyncOp from the ConnectionPool. |
| Comments |
| Comment by Githook User [ 23/Sep/15 ] |
|
Author: {u'username': u'amidvidy', u'name': u'Adam Midvidy', u'email': u'amidvidy@gmail.com'}Message: |