[SERVER-37189] transactions.currentActive has a value of -1 Created: 18/Sep/18 Updated: 29/Oct/23 Resolved: 15/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication |
| Affects Version/s: | 4.0.2, 4.1.2 |
| Fix Version/s: | 4.0.6, 4.1.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Isabella Siu (Inactive) | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||
| Steps To Reproduce: | on a secondary:
|
||||||||||||||||
| Sprint: | Repl 2018-10-22, Repl 2018-11-05, Repl 2018-11-19 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||
| Description |
|
Got a value of -1 for the currentActive transactions when running serverStatus against a replica set secondary.
|
| Comments |
| Comment by Githook User [ 21/Dec/18 ] |
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: (cherry picked from commit 06dd323b423deccb5fbb650ddbed0135c00191d2) |
| Comment by Githook User [ 15/Nov/18 ] |
|
Author: {'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}Message: |
| Comment by William Schultz (Inactive) [ 19/Sep/18 ] |
|
Yep, looks like there is an issue here with how we update internal transaction metadata when the first command of a transaction fails against a secondary. On secondaries, we don't actually fail the transaction until the first command is executed. Before this, we treat the transaction as if it was started inside TransactionParticipant::_beginMultiDocumentTransaction. This would increase the currentActive count to 1. When the command invocation fails with NotMaster, we don't actually throw an exception, but return an ok:0 response. This means that we don't try to abort the transaction here. So, even though the transaction appears to fave "failed" to begin, the internal transaction metadata indicates that there is a transaction in-progress, and the metrics counters reflect that. I need to investigate a bit more to determine the solution to this, but we may need a better way of failing transactions early if they are run against secondaries. I attached an additional repro that demonstrates the issue, against master branch as well. |
| Comment by Isabella Siu (Inactive) [ 19/Sep/18 ] |
|
william.schultz I do not have test commands enabled, and it does not occur if it is run against a primary. |
| Comment by Bruce Lucas (Inactive) [ 19/Sep/18 ] |
|
Working from her repro,
Note that even though this only occurs on a secondary where transactions are not allowed, if that secondary were then promoted to primary I assume the accounting error would persist. |
| Comment by William Schultz (Inactive) [ 18/Sep/18 ] |
|
isabella.siu In 4.0, we explicitly disallow transactions on replica set secondaries. See Note: Transactions will be allowed to run against secondaries if test commands are enabled, so it might be worth checking that in your setup. |
| Comment by Isabella Siu (Inactive) [ 18/Sep/18 ] |