[SERVER-22349] Potential hang in javascript if killOp() occurs while loading system.js functions Created: 29/Jan/16 Updated: 18/Nov/16 Resolved: 08/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript, MapReduce |
| Affects Version/s: | 3.1.7 |
| Fix Version/s: | 3.2.3, 3.3.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Mira Carey |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-only | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Backport Completed: | |||||
| Sprint: | Platforms 10 (02/19/16) | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
After injecting functions from the system.js collection to the global scope of the JavaScript context, map-reduce acquires a lock on the database in MODE_S. Every 100 times the plan executor is ADVANCED, the operation context is checked to see if it has been interrupted. If the mapper function takes a long time to execute, then operations that acquire a lock on the database in MODE_X or MODE_IX will block behind the JavaScript execution. However, it seems undesirable to execute potentially long-running JavaScript (e.g. the mapper or reducer) if the map-reduce operation was interrupted in Scope::loadStored(). Some of the test cases in mr_killop.js use non-terminating mapper and reducer functions. This has been the source of build failures when running mr_killop.js as part of the parallel suite (i.e. jstests/parallel/basic.js and jstests/parallel/basicPlus.js) because the killOp() occurs while loading the stored functions. I have only been able to reproduce this issue when running with SpiderMonkey (default JavaScript engine since 3.1.7+), but I'm not familiar enough with the V8 integration to know for certain that it isn't also affected. |
| Comments |
| Comment by Githook User [ 10/Feb/16 ] | ||||||||||||
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: The JS engine's loadStored eats exceptions that occur while it's loading Re-throwing interrupts from the try/catch block around loadStored fixes (cherry picked from commit 93f767caeebda5ffd295f935e734e0bf02da3356) | ||||||||||||
| Comment by Githook User [ 08/Feb/16 ] | ||||||||||||
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: The JS engine's loadStored eats exceptions that occur while it's loading Re-throwing interrupts from the try/catch block around loadStored fixes | ||||||||||||
| Comment by Githook User [ 05/Feb/16 ] | ||||||||||||
|
Author: {u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}Message: Revert " This reverts commit dfc320fe9c8a5227b08c77a87f52996cf40b0206. | ||||||||||||
| Comment by Githook User [ 05/Feb/16 ] | ||||||||||||
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: The JS engine's loadStored eats exceptions that occur while it's loading Removing the try/catch block around loadStored fixes this behavior. | ||||||||||||
| Comment by Mira Carey [ 05/Feb/16 ] | ||||||||||||
|
This can also occur in group and $where | ||||||||||||
| Comment by Max Hirschhorn [ 29/Jan/16 ] | ||||||||||||
|
The following patch seems to resolve the issue (in map-reduce at least). It's unclear whether this affects other places where JavaScript is evaluated on the server-side, e.g. $where and db.eval().
We may want to do one or both of the following:
|