[SERVER-39281] Interrupt during rename part of map-reduce with "replace" not handled gracefully Created: 30/Jan/19 Updated: 06/Dec/22 Resolved: 21/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MapReduce |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Justin Seyster | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Operating System: | ALL |
| Participants: |
| Description |
|
When a map-reduce has "replace" for its output, it writes to a temp collection that gets renamed to the output collection./ This rename has two problems: 1) If the rename gets interrupted, the m/r operation swallows the Interrupted error and instead results in a non-specific error. Calling code doesn't know that the failure was caused by an interrupt. 2) The output collection has already been deleted. We don't explicitly guarantee that the replacement is atomic, but it's kind of a shame if an interrupt occurs after the old collection has been deleted but before the new output has been renamed, leaving the user with no data. |
| Comments |
| Comment by David Storch [ 21/Jun/19 ] |
|
Closing as Won't Fix, as I don't think we're pursuing code changes to the old mapReduce implementation right now. The query team has plans to replace our mapReduce implementation with a more modern one that shares infrastructure with the aggregation subsystem. |