[
https://issues.apache.org/jira/browse/GEODE-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt updated GEODE-7069:
------------------------------------
Description:
Bill Burcham and I spent a day walking through WAN location discovery code and
have suggestions for improvements:
After exchanging information about locators the WAN location discovery
exchangeRemoteLocators method goes into a "ping" loop that doesn't do anything
useful & should be removed.
Neither the receiving end nor the sending end of the
RemoteLocatorPingRequest/Response messages does anything useful. You might
also argue that the whole exchangeRemoteLocators step of locator discovery is
useless since the exchangeLocalLocators step communicates with all known remote
locators.
WAN locator discovery seems to present itself as a "membership" system but has
no coordinator or failure detection. It might be useful to think about
reimplementing this whole discovery mechanism as a "gossip" based service that
times out entries unless they are refreshed periodically. The
exchangeRemoteLocators thread could then be made to perform that refresh.
The WAN location service should also be modified to register the messages it
handles with TcpServer and it should be registered as a TcpHandler. The odd
LocatorMembershipListenerImpl.handleRequest() method can then be removed from
PrimaryHandler's processRequest() method. Special handling of this class in
auto-reconnect and shutdown code could then also be removed.
was:
After exchanging information about locators the WAN location discovery
exchangeRemoteLocators method goes into a "ping" loop that doesn't do anything
useful & should be removed.
Neither the receiving end nor the sending end of the
RemoteLocatorPingRequest/Response messages does anything useful. You might
also argue that the whole exchangeRemoteLocators step of locator discovery is
useless since the exchangeLocalLocators step communicates with all known remote
locators.
WAN locator discovery seems to present itself as a "membership" system but has
no coordinator or failure detection. It might be useful to think about
reimplementing this whole discovery mechanism as a "gossip" based service that
times out entries unless they are refreshed periodically. The
exchangeRemoteLocators thread could then be made to perform that refresh.
The WAN location service should also be modified to register the messages it
handles with TcpServer and it should be registered as a TcpHandler. The odd
LocatorMembershipListenerImpl.handleRequest() method can then be removed from
PrimaryHandler's processRequest() method. Special handling of this class in
auto-reconnect and shutdown code could then also be removed.
> WAN locator discovery needs to be improved
> ------------------------------------------
>
> Key: GEODE-7069
> URL: https://issues.apache.org/jira/browse/GEODE-7069
> Project: Geode
> Issue Type: Improvement
> Components: locator, wan
> Reporter: Bruce Schuchardt
> Priority: Major
>
> Bill Burcham and I spent a day walking through WAN location discovery code
> and have suggestions for improvements:
> After exchanging information about locators the WAN location discovery
> exchangeRemoteLocators method goes into a "ping" loop that doesn't do
> anything useful & should be removed.
> Neither the receiving end nor the sending end of the
> RemoteLocatorPingRequest/Response messages does anything useful. You might
> also argue that the whole exchangeRemoteLocators step of locator discovery is
> useless since the exchangeLocalLocators step communicates with all known
> remote locators.
> WAN locator discovery seems to present itself as a "membership" system but
> has no coordinator or failure detection. It might be useful to think about
> reimplementing this whole discovery mechanism as a "gossip" based service
> that times out entries unless they are refreshed periodically. The
> exchangeRemoteLocators thread could then be made to perform that refresh.
> The WAN location service should also be modified to register the messages it
> handles with TcpServer and it should be registered as a TcpHandler. The odd
> LocatorMembershipListenerImpl.handleRequest() method can then be removed from
> PrimaryHandler's processRequest() method. Special handling of this class in
> auto-reconnect and shutdown code could then also be removed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
