[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566099#comment-15566099
]
Jinmei Liao commented on GEODE-1986:
------------------------------------
Created a DUnit Test to surface this problem:
public class ClusterConfigWithEmbededLocatorDUnitTest extends
JUnit4DistributedTestCase {
protected VM locator = null;
@Before
public void before() throws Exception {
final Host host = Host.getHost(0);
this.locator = host.getVM(0);
}
@Test
public void testPeerCache() throws Exception{
int locatorPort = AvailablePortHelper.getRandomAvailableTCPPort();
locator.invoke(()->{
new CacheFactory()
.set("name", this.getName()+".server1")
.set("mcast-port", "0")
.set("log-level", "config")
.set("start-locator", "localhost["+locatorPort+"]")
.create();
});
new CacheFactory()
.set("name", this.getName()+".server2")
.set("mcast-port", "0")
.set("log-level", "config")
.set("locators", "localhost["+locatorPort+"]")
.create();
}
}
The reason we moved the conditional check
(https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958)
to a few lines below is that we can't allow server to start if not using
cluster config while the locator is started with security, that's why we need
to find out if the locator is secure or not by requesting the configuration
from the locator first, then do the check. I believe the root of the problem is
that the call to
this.getDistributionManager().getAllHostedLocatorsWithSharedConfiguration()
should be empty in the embedded locator case, but it would still return that
locator, that why it's trying to request the cluster config from that locator.
Do you know quickly how to correctly have
getAllHostedLocatorsWithSharedConfiguration not return the embedded locator?
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> -------------------------------------------------------------------------------
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
> Reporter: John Blum
> Assignee: Jinmei Liao
> Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
