[SERVER-47917] The JournalFlusher is hitting WriteConflictExceptions thrown by EBUSY cursor errors caused by the validate cmd doing WT:verify on the same collection Created: 04/May/20 Updated: 27/Oct/23 Resolved: 05/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Sprint: | Execution Team 2020-05-18 | ||||
| Participants: | |||||
| Linked BF Score: | 35 | ||||
| Description |
|
The JournalFlusher is reading the oplog collection without any collection level locks, so it can run concurrently with a full:true validate command on the same collection. Opening a cursor while validate calls WT:verify will cause a WT EBUSY error, which MongoDB converts into a WriteConflictException. Query normally retries reads when given a WRITE_CONFLICT_RETRY_ONLY yield policy, but for some reason it gets to the retry code and finds a NO_YIELD policy.
|
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 05/May/20 ] |
|
This is not a bug, like I thought it was. Eric helped explain. The YieldPolicy passed into the PlanExecutor only applies when a query yields. If the query is just starting and it immediately hits a WriteConflictException (thrown by the storage integration layer because of a WT EBUSY err) while trying to open a cursor, then there is no YieldPolicy in affect. |