[SERVER-9695] Couldn't kill $where op in features3.js on RHEL 32 Created: 15/May/13 Updated: 11/Jul/16 Resolved: 17/May/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 2.4.4, 2.5.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Whalen (Inactive) | Assignee: | Ben Becker |
| Resolution: | Done | Votes: | 0 |
| Labels: | buildbot | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
http://buildlogs.mongodb.org/Nightly%20Linux%20RHEL%2032-bit/builds/497/test/sharding/features3.js
|
| Comments |
| Comment by auto [ 22/May/13 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by auto [ 17/May/13 ] |
|
Author: {u'date': u'2013-05-17T13:30:51Z', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Eric Milkie [ 17/May/13 ] |
|
I spent some time looking at this. In a proper executing test, there are two $where ops to be killed. In the failing case, only one of the two is being killed. This is because in the assert.soon loop, we attempt to do too many things. We attempt to list all the processes, search for the $where ops, kill them, and then wait for their demise. All in one loop! |
| Comment by Ben Becker [ 16/May/13 ] |
|
ian@10gen.com, I would suggest removing the $where portion of the test (assuming the intended behavior has been confirmed). |
| Comment by Ian Whalen (Inactive) [ 16/May/13 ] |
|
ben are you thinking we should kill the whole test? change it somehow? can you make a suggestion on how to proceed here? |
| Comment by Ben Becker [ 16/May/13 ] |
|
tad, yes, I think the $where/killOp part of the test is invalid. |
| Comment by Tad Marshall [ 16/May/13 ] |
|
Is this an invalid test then? ... testing something that can't be expected to always work? |
| Comment by Ben Becker [ 16/May/13 ] |
|
I don't think there's anything that can be done here. The operation correctly didn't yield before the timeout, so there's never a check for a pending kill request. The only way to 'fix' this would be to move the pending kill request outside of the yield logic. While this would be more logical, it may introduce a new concurrency bottleneck (in checkForInterrupt()), and only fixes this contrived test case. |
| Comment by Ian Whalen (Inactive) [ 16/May/13 ] |
|
benjamin.becker any thoughts/progress on this? seems to be a 2.5.0 blocker. |