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

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

Commit dbd7c959963a065d2383c042597f64e8dfb45b1f in geode's branch 
refs/heads/develop from [~masaki.yamakawa]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dbd7c95 ]

GEODE-2812: Add API to get list of live locators

There is a Geode cluster using a logical member group, and from the
client, the connection pool to the logical member group is connected
using the PoolFactory API at the timing when connection becomes
necessary.
At this time, even though the locator that was running at the initial
connection stops due to reasons such as regular maintenance etc., even
if the alternate locator is started before maintenance, I can not
connect to the locator in the static initial list.

1. Client side:PoolManager.createFactory().addLocator("localhost",
10334).setServerGroup("GroupA").create("pool1");
2. Geode cluster:start locator[localhost:10335].
3. Geode cluster:stop locator[localhost:10334].
4. Client side:PoolManager.createFactory().addLocator("localhost",
10334).setServerGroup("GroupB").create("pool2");

Therefore, I would like to decide the connection destination based on
the live locator list of another logical member group.
I added an API that can get the list of live locators from the Pool. Use
the API as follows:

Pool pool = PoolManager.createFactory()
  .addLocator("localhost", 10334)
  .setSubscriptionEnabled(true).setServerGroup("GroupA")
  .create("GroupAPool");

List<InetSocketAddress> = pool.getLiveLocators();

Note:
The list of live locators gets the result of the UpdateLocatorListTask
periodically running in AutoConnectionSourceImpl.
Therefore, whether or not it is alive will cause a time lag, depending
on the task execution interval.
Also, the result of ExplicitConnectionSourceImpl without using a locator
is always empty.


> Add API to get list of live locators
> ------------------------------------
>
>                 Key: GEODE-2812
>                 URL: https://issues.apache.org/jira/browse/GEODE-2812
>             Project: Geode
>          Issue Type: Improvement
>          Components: client/server
>            Reporter: Masaki Yamakawa
>            Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List<InetSocketAddress> = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to