Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
None
-
Fully Compatible
-
ALL
-
Repl 2018-08-13, Repl 2018-08-27
-
18
Description
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.
Attachments
Issue Links
- 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
-