[jira] [Commented] (GEODE-7585) Add API to Membership to start a locator

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17009233#comment-17009233 ] 

ASF subversion and git services commented on GEODE-7585:
--------------------------------------------------------

Commit 65260ef6cec059f6da5b1877941e4a86bf8c0179 in geode's branch refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=65260ef ]

GEODE-7585: Create API for starting a locator in the membership package

Creating a new MembershipLocator and MembershipLocatorBuilder that are used to
create the membership locator. These classes encapsulate the TcpServer,
PrimaryHandler, and GMSLocator that were previously held by InternalLocator.

Getting rid of some intermdiate classes that wrapped the GMSLocator -
NetLocator and GMSLocatorAdapter.

Refactoring the restart logic out of PrimaryHandler. There is now a separate
RestartHandler, and a separate collection that tracks RestartHandlers. Removing
RestartableTcpHandler.

Removing TcpServerFactory.


> Add API to Membership to start a locator
> ----------------------------------------
>
>                 Key: GEODE-7585
>                 URL: https://issues.apache.org/jira/browse/GEODE-7585
>             Project: Geode
>          Issue Type: Improvement
>          Components: membership
>            Reporter: Bill Burcham
>            Assignee: Bill Burcham
>            Priority: Major
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> After we have decoupled the tcpserver package from the rest of core, we would like to have a way to inject a TCPServer configuration into membership.
> Right now the core is directly creating and calling GMSLocator from GMSLocatorAdapter. GMSLocatorAdapter is not going through the membership API, it's interacting with a GMSLocator component that was created before Membership was started. GMSLocator is not part of the membership API.
> Instead, we would like core to only use the membership API, so we should have a better way to inject the TCPServer into membership. We want to have all of the membership code encapsulated behind the the classes in gms.api package (Membership, MembershipBuilder). We also want all of the components of membership to be instantiated when we call MembershipBuilder.create.
> For production, we would have an implementation that would include any core-specific behaviors. For isolated testing of the membership component, we would have an implementation that would include just what is required for membership, which is essentially the ability to register a handler for PeerLocationRequests. The InternalLocator will pass along its additional handlers (and whatever else it needs) to membership.
> For the interface, we might just add another setter to our builder like this:
> MembershipBuilder
> .setTcpServerConfiguration(TcpServerConfiguration)
> ......
> Acceptance Criteria:
>     geode-core code will only interface with the classes in the gms.api package. It will not directly use GMSLocator.
>     We have an API to start the locator part of membership within the membership module.
>     We have a test that starts a locator and connects two members to it, using only the membership module (through it's public API). This should be an integration test (no dunit). Perhaps MembershipJUnitTest could be used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)