[SERVER-25010] Add a Notification object with each object in MetadataManager::_rangesToClean Created: 12/Jul/16 Updated: 13/Aug/16 Resolved: 02/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.11 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Sam Dunietz |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding 18 (08/05/16) | ||||||||
| Participants: | |||||||||
| Description |
|
We need to handle waitForDelete flags from migrations, and cleanupOrphaned commands, that won't continue until the range is deleted. Therefore we'll create a Notification object to return to notify when the range has been removed. A future addition would be to put the range to clean at the head of the a rangesToClean vector of some sort so that it is the next range to be deleted, but we're not going to worry about that right now. Suppose ranges to clean is this right now: map<BSONObj, Range> rangesToClean we're changing it to map<BSONObj, RangeDescriptor> rangesToClean RangeDescriptor has
The Notification will need to be threaded back to the caller somehow. We'll look at the MetadataManager code and figure this out when it is more stable |
| Comments |
| Comment by Githook User [ 02/Aug/16 ] |
|
Author: {u'name': u'Sam Dunietz', u'email': u'sam.dunietz@10gen.com'}Message: Fix compile for |
| Comment by Githook User [ 02/Aug/16 ] |
|
Author: {u'name': u'Sam Dunietz', u'email': u'sam.dunietz@10gen.com'}Message: |