[SERVER-40062] Add failpoint to skip doing retries on WriteConflictExceptions Created: 10/Mar/19 Updated: 29/Oct/23 Resolved: 13/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.9 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Max Hirschhorn |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | STM 2019-03-25 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
An insert or update operation retries ad infinitum on a unique key violation that results from the effects of an active transaction (read: a transaction not yet committed or aborted). This behavior is demonstrated by the write_conflicts_with_non_txns.js test. In order to allow the rollback fuzzer to generate randomized insert and update operations that may trigger unique key violations without hanging, it would be useful to add a failpoint to the writeConflictRetry() function where it doesn't do any retry logic and instead has the command fail with a WriteConflict error response. |
| Comments |
| Comment by Geert Bosch [ 19/Mar/19 ] |
|
Indeed, the concern is with the behavior this is working around. I filed https://jira.mongodb.org/browse/SERVER-40105 and https://jira.mongodb.org/browse/SERVER-40103 for this, and discussed the issues at hand with Aly Cabral who will work on determining priority of these issues relative to other outstanding work. |
| Comment by Judah Schvimer [ 15/Mar/19 ] |
|
geert.bosch, to clarify, your concern is not with the failpoint but with the behavior the failpoint is working around, correct? Is there an action to take on this concern? |
| Comment by Githook User [ 13/Mar/19 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: |
| Comment by Geert Bosch [ 13/Mar/19 ] |
|
I'm somewhat concerned about this behavior for client applications that use transactions, especially as transaction lifetimes may get longer with cross-shard transactions. For prepare conflicts, we at least block until a prepared transaction has been committed, ensuring forward progress, but here clients retrying their writes may actually cause so much load on the server that progress of the transaction that would unblock the writes is limited. Compare with spin lock issues. |