-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Sharding
-
Fully Compatible
-
ALL
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
TransientTransactionErrors were uncovered on multiple tests when running a custom jsCore passthrough suite with the Logical Session Cache refresh set to 100ms.
The cleanest example of this error is in multi_statement_transaction – but there aren't any log lines in this test to investigate.
assert: command failed: { errorLabels" : [ [js_test:multi_statement_transaction] 2018-08-28T20:34:41.039+0000 "TransientTransactionError" [js_test:multi_statement_transaction] 2018-08-28T20:34:41.039+0000 ], [js_test:multi_statement_transaction] 2018-08-28T20:34:41.039+0000 "operationTime" : Timestamp(1535488481, 2), [js_test:multi_statement_transaction] 2018-08-28T20:34:41.039+0000 "ok" : 0, [js_test:multi_statement_transaction] 2018-08-28T20:34:41.043+0000 "errmsg" : "Unable to acquire lock '{6237343057549539649: Database, 1625657039122151745, config}' within a max lock request timeout of '5ms' milliseconds.", [js_test:multi_statement_transaction] 2018-08-28T20:34:41.043+0000 "code" : 24, [js_test:multi_statement_transaction] 2018-08-28T20:34:41.043+0000 "codeName" : "LockTimeout", [js_test:multi_statement_transaction] 2018-08-28T20:34:41.050+0000 "$clusterTime" : { [js_test:multi_statement_transaction] 2018-08-28T20:34:41.051+0000 "clusterTime" : Timestamp(1535488481, 2), [js_test:multi_statement_transaction] 2018-08-28T20:34:41.051+0000 "signature" : { [js_test:multi_statement_transaction] 2018-08-28T20:34:41.052+0000 "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), [js_test:multi_statement_transaction] 2018-08-28T20:34:41.052+0000 "keyId" : NumberLong(0) [js_test:multi_statement_transaction] 2018-08-28T20:34:41.052+0000 } [js_test:multi_statement_transaction] 2018-08-28T20:34:41.052+0000 } [js_test:multi_statement_transaction] 2018-08-28T20:34:41.053+0000 }
The error also persists in the collation and transactions_profiling_with_drops tests (which have plenty of logs to look at).
After a cursory investigation of collation.js: it seems that a connection takes an exclusive write lock on config.system.sessions for an attempted update, then the LogicalSessionCache thread tries to take the lock as well – then fails. Check the highlighted lines on this Lobster log.
- is caused by
-
SERVER-36961 createIndexes command should check if index already exists with weak lock
-
- Closed
-
- is related to
-
-
- Closed
-