[SERVER-44513] Implement TopologyCoordinator::awaitTopologyChange Created: 08/Nov/19 Updated: 29/Oct/23 Resolved: 05/Dec/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Jason Chan |
| 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: | Repl 2019-11-18, Repl 2019-12-02, Repl 2019-12-16 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Implement TopologyCoordinator::awaitTopologyChange. For this first ticket, only declare TopologyVersion struct, the TopologyCoordinator::topologyVersion field, and the awaitTopologyChange method, but don't react to actual topology changes, just wait for maxAwaitTimeMS. |
| Comments |
| Comment by Githook User [ 05/Dec/19 ] | |||||||||
|
Author: {'name': 'Jason Chan', 'username': 'jasonjhchan', 'email': 'jason.chan@mongodb.com'}Message: | |||||||||
| Comment by Tess Avitabile (Inactive) [ 14/Nov/19 ] | |||||||||
|
jesse, I'm considering take a different approach for the implementation than the one described in the ticket, and I want to hear your thoughts. I don't think we should share code with ReplicationCoordinatorImpl::_startWaitingForReplication() because the use cases are different. In _startWaitingForReplication(), we have a list of waiters ordered by OpTime, and we must notify waiters up to a certain OpTime. For topology version, all the waiters will get notified at once. This is because an isMaster command will either have a stale topology version (in which case we respond immediately), a future topology version (which is an error), or the current topology version, in which case we wait for the next topology change. Because all waiters will get notified at once, ldeng and I discussed that they could all wait on a single shared future (or perhaps one future per horizon, but more on that later). I've also been thinking about I would like to propose a different implementation as follows:
For this ticket, we never fulfill the promises, so waiting would always time out. How does this approach sound to you? EDIT: We agreed on the implementation described in this comment. | |||||||||
| Comment by Githook User [ 13/Nov/19 ] | |||||||||
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: |