[SERVER-45304] Include resolved IP address in rs.status() Created: 26/Dec/19 Updated: 08/Jan/24 Resolved: 27/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Lingzhi Deng | Assignee: | Amirsaman Memaripour |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||||||||||||||||
| Sprint: | Service Arch 2020-02-10, Service Arch 2020-02-24 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Description |
|
Same as |
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 27/Feb/20 ] |
|
After talking with mira.carey@mongodb.com, we think that we need to reconsider this feature. DNS queries take time and we're not at all certain we're serving people's needs in the best way. If you think this would have been useful to you, I encourage you to reach out so we can serve your needs more sustainably in the future. |
| Comment by Githook User [ 27/Feb/20 ] |
|
Author: {'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}Message: |
| Comment by Githook User [ 27/Feb/20 ] |
|
Author: {'name': 'Jason Carey', 'username': 'hanumantmk', 'email': 'jcarey@argv.me'}Message: Revert " This reverts commit 5df8e1c88ce190d6289880db1f4018409be573ac. |
| Comment by Amirsaman Memaripour [ 26/Feb/20 ] |
|
william.schultz Considering the current implementation, TopologyCoordinator does not init() or shutdown() the service, and it owns the instance as the service essentially complements the functionality of TopologyCoordinator. The decision is simply made base on separation of concerns and to minimize exposure to the rest of the system, since TopologyCoordinator is really the only component concerned with IPAddrLookupService. Moving the service to ReplicationCoordinator and passing its reference to TopologyCoordinator is a possible design, but it essentially exposes ReplicationCoordinator to a service it never uses directly. There are of course tradeoffs here, and the current design is more biased towards separation of concerns. |
| Comment by William Schultz (Inactive) [ 26/Feb/20 ] |
|
amirsaman.memaripour It appears that this patch has added a new "service" that runs a background thread inside the TopologyCoordinator. Generally, the TopologyCoordinator is intended to be the core "state machine" of the replication protocol and shouldn't need be starting up or shutting down threads. Is there a good reason you decided to have this IP address lookup service owned by the TopologyCoordinator? I'm not convinced it's the right place for it. Moving it to the ReplicationCoordinator layer might be slightly better, but I'm not sure. From looking at the places we call into the IPAddrLookupService inside TopologyCoordinator, it doesn't seem that it would fundamentally have to be owned by the TopologyCoordinator. It could perhaps be owned and started up by someone else and a reference could be passed in to the TopologyCoordinator in the functions that need it? |
| Comment by Githook User [ 21/Feb/20 ] |
|
Author: {'username': 'samanca', 'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com'}Message: |