-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Diagnostics
-
None
-
Fully Compatible
-
ALL
-
Repl 2018-08-13, Repl 2018-08-27
-
18
Same test as SERVER-36294 - 10 threads doing simple udpates to single independent documents.
At A 6 of the 10 threads got a TransientTransactionError, apparently (based on timing in chart above) because the in-progress transaction reaper job prevented them from acquiring a lock within 5ms:
Error: command failed: { "errorLabels" : [ "TransientTransactionError" ], "operationTime" : Timestamp(1532607909, 727), "ok" : 0, "errmsg" : "Unable to acquire lock '{6237343057549539649: Database, 1625657039122151745}' within a max lock request timeout of '5ms' milliseconds.", "code" : 24, "codeName" : "LockTimeout", "$clusterTime" : { "clusterTime" : Timestamp(1532607909, 727), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } }
The 10 threads continue, but the open and active counters are now stuck ranging from 6-16 instead of 0-10. Apparently the counters have not been decremented on the error.
At B I killed the mongo shell. It appears there was still one transaction open at that point because open is 7 and inactive is 1. At C after that transaction times out we remain stuck indefinitely with open at 6 and active at 6.
- depends on
-
SERVER-36421 Commit transaction command does not properly abort the transaction if onTransactionCommit throws an exception
- Closed
- is related to
-
SERVER-36294 Sum of currentActive and currentInactive not equal to currentOpen transactions
- Closed