[SERVER-28884] CollectionRangeDeleter track deletions more reliably Created: 20/Apr/17 Updated: 30/Oct/23 Resolved: 17/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.5.7 |
| Fix Version/s: | 3.5.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nathan Myers | Assignee: | Nathan Myers |
| 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: | Sharding 2017-05-29 | ||||||||
| Participants: | |||||||||
| Description |
|
In current code, each metadata version has provisioned one range to delete when it is retired. Registering a second range would require copying the metadata to a new version (if there is no other event that required the copy), a potentially expensive operation. Keeping a list of ranges for each metadata version would simplify the code and avoid otherwise-unnecessary metadata copying. Furthermore, the event-managing code has a race in which a deletion could fail while the requester is not waiting, resulting in the failure not being reported to the requester, and then, possibly, in-migration to a range currently occupied. Solving this requires plumbing range deletion event notification through more levels of interface. |
| Comments |
| Comment by Githook User [ 17/May/17 ] |
|
Author: {u'username': u'ncm', u'name': u'Nathan Myers', u'email': u'ncm@cantrip.org'}Message: |
| Comment by Nathan Myers [ 15/May/17 ] |
|
See also comments on 133320002: |