-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: MapReduce
-
Fully Compatible
-
ALL
-
0
Build failures were observed in the concurrency workloads that result in the following error:
2015-01-15T13:28:25.142+0000 I QUERY Error: 1 thread threw
Error: command failed: {
"errmsg" : "exception: JavaScript execution terminated",
"code" : 16721,
"ok" : 0
} : undefined
at quietlyDoAssert (jstests/concurrency/fsm_libs/assert.js:53:15)
at Function.assert.commandWorked (src/mongo/shell/assert.js:254:5)
at wrapAssertFn (jstests/concurrency/fsm_libs/assert.js:60:16)
at Function.assertWithLevel.(anonymous function) [as commandWorked] (jstests/concurrency/fsm_libs/assert.js:99:13)
at Object.group (jstests/concurrency/fsm_workloads/group_cond.js:29:27)
at Object.runFSM [as run] (jstests/concurrency/fsm_libs/fsm.js:19:16)
at <anonymous>:8:13
at Object.main (jstests/concurrency/fsm_libs/worker_thread.js:68:17)
at ____MongoToV8_newFunction_temp (<anonymous>:5:25)
at ____MongoToV8_newFunction_temp (<anonymous>:3:24)
at throwError (jstests/concurrency/fsm_libs/runner.js:261:23)
at jstests/concurrency/fsm_libs/runner.js:390:17
at Array.forEach (native)
at runWorkloads (jstests/concurrency/fsm_libs/runner.js:345:22)
at serial (jstests/concurrency/fsm_libs/runner.js:406:13)
at /data/mci/shell/src/jstests/concurrency/fsm_all.js:27:1 at jstests/concurrency/fsm_libs/runner.js:273
failed to load: /data/mci/shell/src/jstests/concurrency/fsm_all.js
Builds that encountered this error include:
- https://mci.10gen.com/task/mongodb_mongo_master_linux_64_debug_2b5bfa7e3799c9b4dffb38856b5d5f893a500731_15_01_20_16_52_02_concurrency_WT_linux_64_debug
- https://mci.10gen.com/task/mongodb_mongo_master_linux_64_lsm_6bab2f390cfbae08bf0801668f54a5fd35db2bfc_15_01_16_21_28_03_concurrency_WT_linux_64_lsm
- https://mci.10gen.com/task/mongodb_mongo_master_windows_64_2k8_debug_bcf19d4af076b5ce4f760b43cbb770c8a941e8c4_15_01_16_01_34_23_concurrency_WT_windows_64_2k8_debug
- https://mci.10gen.com/task/mongodb_mongo_master_rhel55_653169a891f612afef80ec149194f11197fbaa3b_15_01_15_12_30_04_concurrency_WT_rhel55
These seem to be caused by a javascript timeout that we've placed in multiple locations on our own code execution in db/exec/group.cpp:
_scope->exec("$reduce = " + _request.reduceCode, "$group reduce setup", false, true, true, _scope->exec("$arr = [];", "$group reduce setup 2", false, true, true, 100);
Other calls to both exec() and invoke() do not seem to use this timeout. For example, in db/commands/mr.cpp
ScriptingFunction init = _scope->createFunction(
"_emitCt = 0;"
"_keyCt = 0;"
"_dupCt = 0;"
"_redCt = 0;"
"if (typeof(_mrMap) === 'undefined') {"
" _mrMap = {};"
"}");
_scope->invoke(init, 0, 0, 0, true);
Note that in both examples we're not executing client code, we're executing our own server code. It would appear that it is likely that a garbage collection could cause the execution to take more than 100ms but there seems to be no reason to keep the timeout here.
- links to